Data governance glossary

The Data Management Body of Knowledge is the closest thing the profession has to a shared textbook. It defines eleven knowledge areas — governance, architecture, modeling, storage and operations, security, integration and interoperability, document and content, reference and master data, warehousing and business intelligence, metadata, and data quality — and draws them as a wheel with governance at the hub. It is a genuine framework, and a thorough one. The common complaint is that it reads as very theoretical: it tells you what exists and what each part is for, but it is far from obvious how to apply it inside your own company, and the sequencing is left to you.

In practice. Its most useful function is as a gap map. Run a program against the eleven areas and the two or three nobody owns become visible immediately, which is usually more informative than any maturity score. It also settles arguments about words, which is why the CDMP certification is built on it.

Where it goes wrong. Teams treat the wheel as a plan and try to stand up eleven capabilities at once. The wheel is a map of the territory, not a route through it. A first year that does governance, metadata and quality properly on one domain beats a first year that opens eleven workstreams and finishes none.

"Data is an asset" is the most repeated sentence in the field and usually the emptiest. It means something only when it changes a decision, and the test is the one you would apply to a building or a fleet: an asset has an owner, a recorded value, a maintenance cost and a lifecycle that ends. A table nobody owns, nobody can value and nobody will ever delete is not an asset. It is storage. DMBOK defines governance as authority over the management of data assets, so the word is doing real work in that definition.

In practice. Start with the ten datasets that feed executive reporting and answer four questions for each: who owns it, what is it worth, what does it cost us when it is wrong, and when does it go away. Record the answers in the inventory or catalog. The useful measure is the share of assets that have both an owner and an approved definition, and the trend in that number.

Where it goes wrong. A crawler fills the catalog with every table in the estate, and everything it found is now called an asset. Nobody knows what percentage has an owner. Meanwhile nothing is ever retired, because deleting feels risky and keeping costs nothing visible. An asset register that only ever grows is an inventory of liabilities.

Data governance is the exercise of authority and control over the management of data. It does not manage data itself; it decides who does, what they are allowed to decide, which rules they must follow, and who answers when something goes wrong. Everything else people call governance — a catalog, a quality dashboard, a stewards' forum — is either an instrument for making those decisions or evidence that they were made.

In practice. It looks like a short list of named people with named decisions attached to them. Who approves a change to the definition of "active customer". Who signs off that a dataset may leave the finance domain. Who is called when a report and a system disagree. When a governance program is working, that list is written down, current, and known to the people it constrains.

Where it goes wrong. Governance is bought as a tool and staffed as a committee, and neither creates a decision right. A catalog with no owner recorded against a term is a directory; a council with no authority is a meeting. If nobody can point to a decision the program has actually made in the last quarter, there is no governance yet — only its documentation.

A committee exists so governance has somewhere to get authority from. Data owners can settle what a customer is and who approves access to it, but they cannot approve a budget, absorb a regulatory risk on behalf of the company, or tell another executive that a project ships late because its data is not ready. That is why the room is wider than the data team: the C-level sponsor who owns the P&L, the data protection officer, the cybersecurity director, and usually legal, internal audit and the domain owners whose data is on the agenda.

In practice. It meets quarterly, not monthly, because it decides fewer and bigger things than a council: the policy set, the funding, the risk appetite, the priority domains, and the escalations the council could not close. Every item arrives with a recommendation attached and leaves with a name against it. The DPO and the security lead are members rather than reviewers, which is what stops a privacy or security objection from landing three weeks after a decision was already made.

Where it goes wrong. Only data people show up. A committee of the CDO, two analysts and a consultant can recommend anything and fund nothing, and after two meetings it becomes a project status review with an executive title. The other failure is the opposite: thirty invitees, a fifty-slide deck, and a decision log that has been empty since the kickoff.

A framework is the parts list for governance. Most reduce to four components: roles and responsibilities (owners, stewards, custodians), policies and standards, decision bodies such as a council, and oversight that measures whether any of it is happening. Reference frameworks like DAMA-DMBOK and DCAM describe what good looks like across the whole discipline. Your own framework is the version of that structure you have chosen to build. It is not the operating model, which says who in your organization fills each part and how decisions actually move.

In practice. Borrow the vocabulary early and the scope late. Using the standard words for owner, steward and critical data element costs nothing and settles a category of arguments. Sequencing is a different matter: a framework presents its areas as peers, and the order you build them in should come from where your escalations come from, not from the chapter order.

Where it goes wrong. The framework diagram becomes the deliverable. It gets a slide, a charter and a launch, and every box on it is filled with a role nobody holds. A framework tells you what a complete program contains. Until the boxes have names in them, nothing has been governed.

A program is how governance arrives in an organization: an executive sponsor, a scope, named people with agreed time, and a plan for the next couple of quarters. A first one is smaller than most people expect. It rests on six foundations: treat data as an asset in a way that changes decisions, cut the estate into domains, name owners and stewards, write a policy set short enough to read, keep a simple inventory, and fix a little data quality where people can see it. None of that requires a platform.

In practice. Two domains, named owners and stewards, five policies, one spreadsheet, three measured attributes. That is a complete first quarter, and order matters: domains before roles, roles before policy, policy before catalog, catalog before measurement. Get each steward's manager to agree to the time in writing, because a day job with deadlines beats governance without them.

Where it goes wrong. The program is run as a project with an end date. There is a charter, a burst of activity and a completion report, and the original problem is untouched: eleven policies approved and two departments still bringing different revenue figures to the same review. Governance behaves like operations. The program gets it started; something permanent has to keep it going after the launch.

Data management is the execution work: modeling, integrating, storing, securing, moving, archiving and eventually deleting data. It is what data engineers, DBAs, architects and analysts do. Governance decides the rules; management builds and operates within them. The DAMA-DMBOK treats governance as the hub at the center of eleven management disciplines precisely to keep the two from being confused.

In practice. The distinction is easiest to see in a single request. "Customer email should never be blank" is a governance decision — someone with authority over the customer domain declared it. Adding a NOT NULL constraint, backfilling the 40,000 rows that violate it, and monitoring for new violations is data management.

Where it goes wrong. Organizations hire data management and call it governance. The platform gets built, the pipelines run, and nobody has decided what the numbers mean, so the same field is loaded three ways for three consumers who each believed theirs was the definition. The reverse failure is quieter and just as common: a governance function that produces policy no engineering team was ever resourced to implement.

A data policy states a requirement and names who is accountable for meeting it. "Personal data is retained no longer than the purpose it was collected for requires." "Every critical data element has a named owner." Policies are deliberately few, deliberately short, and deliberately boring — they are the layer that does not change when the tooling does. The detail of how to comply belongs in a standard or a procedure underneath.

In practice. A workable policy set for a mid-sized organization is five to ten pages in total, each policy fitting on one page, each with an owner, an approval date and a review date. If it cannot be read in an afternoon by someone it applies to, it will not be.

Where it goes wrong. Two failure modes, both fatal. The first is the forty-page policy written to satisfy an auditor, which nobody reads and which therefore governs nothing. The second is a policy approved by a data team rather than by the business function it constrains: the moment it costs someone a deadline, it turns out to have had no authority behind it.

If a policy says "customer contact details must be usable", the standard says what usable means: email matches a valid format, country code is ISO 3166-1 alpha-2, phone is stored in E.164, address is validated against the postal reference file. A standard is written to be checked by a machine. That is the difference between it and a policy — a policy is a commitment, a standard is a specification.

In practice. Standards are where governance stops being abstract, because each one can become a data quality rule with a threshold and a dashboard. The useful sequence is short: name the critical data element, write the standard for it, implement it as a rule, report the breach rate.

Where it goes wrong. Standards are written for everything instead of for what matters, which produces a document nobody can implement and a backlog nobody will fund. Twenty standards covering the fields that appear in regulatory reporting and executive dashboards beat two hundred covering every column in the warehouse.

A council exists for cross-domain conflict. Two functions want incompatible definitions of the same entity; a policy would cost one department a quarter's roadmap; a domain wants to expose data that another domain is regulated on. Those cannot be resolved inside a domain, and escalating each one to an executive committee does not scale. The council is the standing place where they are resolved, by the people accountable for the domains involved.

In practice. A council that works is small — the data owners, chaired by someone with executive weight — meets monthly, and works from a queue of specific decisions with a proposed answer attached. Minutes record what was decided and by whom, which is what makes it authority rather than discussion.

Where it goes wrong. The council becomes a status meeting. Twenty attendees, a deck, a round of updates, no decisions, and within two quarters the owners send delegates instead of attending. The reliable test: if the agenda does not contain the word "approve", cancel the meeting and write an email.

A data owner is senior enough that their decisions stick. They approve definitions, authorize access, accept or reject quality tolerances, and carry the consequence when the domain's data fails somebody downstream. Ownership is accountability, not custody: the owner rarely touches the data and almost never fixes it personally. What distinguishes a real owner from a nominal one is that they can say no to a request from another function and be respected.

In practice. Ownership sits with the business leader whose objectives depend most on the domain — commercial for customer, operations for product, HR for employee. It is one named person, never a team and never a committee, and it appears in their objectives rather than in a slide.

Where it goes wrong. Ownership gets assigned to IT, which has custody but no authority over meaning, or spread across a "working group", which means the next disputed definition has nobody to settle it. The clearest symptom is a request to change a definition that circulates for six weeks: that is not a slow process, it is an absent owner.

A steward is the operating half of ownership. They write and maintain the definitions in the business glossary, translate policy into rules, triage quality issues, and are the first call when a number looks wrong. They are chosen for expertise, not seniority — usually the person the rest of the team was already asking, informally, before this role existed. The best stewards were already doing most of the job unpaid and undocumented.

In practice. Stewardship is a named percentage of a real job, not a title added to a full workload. Ten to twenty percent, protected, with the owner's backing, is the difference between a steward network that works and one that quietly stops meeting after four months.

Where it goes wrong. Stewards are appointed in bulk, given a template and no time, and asked to document everything. Nothing gets documented, and the program concludes that the business is not engaged. Steward capacity is the single most common thing to be under-resourced in a governance program, and the easiest to fix.

Stewardship is the mechanism that turns authority into effect. A council can decide that "revenue" has one definition; stewardship is what finds the four systems where it is calculated differently, gets three of them changed, and documents the fourth as a known exception. As a discipline it is mostly unglamorous: maintaining a glossary, chasing an issue across two teams, explaining the same definition to a new analyst for the fifth time.

In practice. A stewardship model names, per domain, who the owner is, who the stewards are, how a definition change is proposed and approved, and where issues are logged. Written down, that is two pages, and those two pages are the operating model most programs are missing.

Where it goes wrong. Stewardship gets treated as documentation work and measured by glossary term count. Term count is a vanity metric — a glossary of 900 terms nobody looks at is worth less than 40 terms that the reporting team actually uses. Measure use and resolution, not volume.

Decision rights are the substance of governance. Not "the council governs customer data", but: who approves a new customer attribute, who approves a change to an existing definition, who grants access to it outside the domain, who accepts a quality tolerance, who declares an incident. Each of those is a distinct decision with a distinct decider, and writing them down is often the single highest-value week a governance program spends.

In practice. A one-page grid — decision down the side, role across the top, one A per row — is enough. The constraint that makes it useful is that every row has exactly one accountable party. Two A's in a row is an unresolved argument written down as if it were a design.

Where it goes wrong. Decision rights are documented as a RACI over activities rather than decisions, which produces a matrix where everyone is consulted on everything and nothing gets faster. The other failure is publishing the grid without telling anyone their name is on it.

Most catalogs were built to be crawled: a scan runs on Sunday night, and by Wednesday the catalog describes a warehouse that no longer exists. Active metadata ingestion inverts that. Every pipeline run, schema change, access grant, failed test and query against a table emits an event, and the metadata platform listens instead of asking. The point is not fresher documentation — it is that metadata arriving in seconds can be acted on automatically, which passive metadata never could.

In practice. Connectors subscribe to what the platform already emits: warehouse query logs, orchestration events, CDC streams, CI runs, IAM changes. Lineage is recomputed per run rather than parsed from SQL once a quarter, popularity and cost come from real usage, and the loop closes on the operational side — a failed quality rule opens a ticket for the named owner, a breaking schema change fails the producer's build, an unused table shows up on the owner's deprecation list, a new column with a personal-data signature gets flagged before anyone queries it.

Where it goes wrong. The feed gets built and the loop does not. Millions of events stream into a catalog that nobody opens, and the only difference from the weekly scan is the invoice. The test is whether any metadata event changes something outside the catalog: an alert, an access review, a blocked deploy. If nothing does, this is a very expensive documentation project.

A business glossary answers "what does this word mean here". Not in general, not in the industry — here, in this company, for reporting purposes. Each entry has a definition, an owner who approved it, the calculation if it is a measure, and ideally the systems and reports where it is implemented. The glossary is where a governance program first becomes visible to people outside it, which makes its quality disproportionately important.

In practice. A glossary earns its existence the first time it settles an argument. Start with the twenty terms that appear in board reporting and are known to be disputed — churn, active customer, revenue, headcount, on-time delivery — and get each one to a single approved definition.

Where it goes wrong. The glossary is built as a completeness exercise, in a tool nobody has in their daily workflow, so definitions are written once and never consulted. A glossary that is not reachable from where people work — the BI tool, the intranet search, the catalog — is a document, not a control.

Certification is a promise attached to a specific asset. Somebody accountable has checked the definition, the source and the quality, and puts their name to it. The badge in the catalog or the BI tool is what makes that promise usable. It lets a reader make a trust decision in a second instead of an hour, and it is what separates the governed margin figure from the four ad-hoc versions next to it. Some organizations use tiers, such as gold for decision-grade data, rather than a single yes or no.

In practice. Certify a few things that matter and make the criteria public: owner, approved definition, quality inside tolerance, known consumers. Treat retirement as a decision too, made by the metric owner with the listed consumers consulted and recent usage as evidence. Measure whether certified assets are reused rather than rebuilt, and whether people are still using them after the first 90 days.

Where it goes wrong. Certification is granted once and never reviewed, so the badge outlives the owner, the definition and the quality checks behind it. The opposite failure is campaigning for people to prefer certified data before any exists. Either way the badge stops meaning anything, and people go back to their own spreadsheets.

A catalog is a search engine for your own data. It answers the two questions that otherwise consume analyst time — does a dataset for this already exist, and can I trust it — by putting technical structure, business definitions and ownership in one place. Most catalogs can harvest structure automatically from warehouses, BI tools and pipelines; none can supply meaning, which is why a catalog is a governance project wearing a tooling budget.

In practice. Catalog adoption tracks a single number: the share of assets people actually search for that have an owner and a definition. Populating the top 200 assets well beats populating 20,000 emptily, and it is the version that gets used twice.

Where it goes wrong. The catalog is bought before the definitions exist and rolled out as the program's deliverable. Six months later it holds every column in the estate, 3% have a description, and the organization concludes that catalogs do not work. The tool worked fine; there was nothing to put in it.

Lineage answers two questions that are otherwise expensive. Upstream: this number looks wrong, where did it come from and what touched it. Downstream: we are changing this field, what breaks. The second is impact analysis, and in organizations with any pipeline complexity it is the one that pays for the whole exercise — the alternative is a change freeze or a discovery in production.

In practice. Lineage is worth capturing at the granularity you will act on. Table-to-table lineage across the pipelines behind regulatory reports is usually enough to answer both questions; column-level lineage across the entire estate is a research project.

Where it goes wrong. Lineage is drawn by hand in a diagramming tool. It is accurate on the day it is drawn and wrong within a sprint, and because it looks authoritative people rely on it after it stops being true. Lineage that is not derived from the pipelines themselves has a shelf life measured in weeks.

Master data is the data that appears in every system: the customer that exists in CRM, billing, support and the warehouse, in four slightly different versions. MDM is the practice of resolving those into one record with a known identifier, and of deciding which system may change which attribute. It is technical work with a governance prerequisite, because matching rules and survivorship rules are business decisions dressed as configuration.

In practice. MDM projects succeed when they start from a specific pain — duplicate customers inflating the churn rate, a supplier paid twice — and cover one entity. They fail when they start from the ambition of a single customer view across the enterprise.

Where it goes wrong. The matching threshold is set by the implementation team. Somebody has to decide whether merging two records that are 92% similar is acceptable, and the consequence of a wrong merge is a customer seeing another customer's data. That is an owner's decision, and delegating it to a configuration screen is how MDM becomes a privacy incident.

Metadata is usually split three ways. Business metadata is meaning — the definition of "active customer", the owner, the sensitivity classification. Technical metadata is structure — table, column, type, nullability, the job that populates it. Operational metadata is behavior — when the load last ran, how many rows arrived, how many failed validation. A governance program needs all three, but it only ever has budget to start with one.

In practice. Start with business metadata for the data that already appears in decisions, because that is where the absence hurts: an analyst who cannot tell which of two revenue columns is the reported one is losing an hour a week to something a sentence would fix.

Where it goes wrong. Metadata is harvested wholesale because a tool can do it automatically, which yields a catalog of 40,000 technical entries with no meaning attached. Automated harvesting is the cheap half. The expensive half is a human deciding what each thing means, and no tool has ever done that part.

The cost shows up in places nobody labels as data: reworked invoices, undeliverable shipments, analysts reconciling two reports by hand, a marketing spend against duplicated contacts, a regulatory resubmission. Each is small and each has an owner who has stopped noticing it, which is why the total is invisible until someone adds it up. Adding it up is usually the most persuasive thing a governance program ever does.

In practice. Cost three specific failures rather than estimating a global figure. Hours × loaded rate × frequency, plus any direct spend. Three credible, defensible numbers from processes the business recognizes will do more for a business case than a benchmark percentage of revenue.

Where it goes wrong. The figure is sourced from a vendor study — "bad data costs companies 15–25% of revenue" — and presented as this company's number. A CFO will discount it in one sentence, and the credibility does not come back. Your own three examples, however modest, survive the question "where did that come from".

Criticality is a triage device. No organization can govern every field, so the CDE list is the honest answer to "which ones actually matter". A field is critical if it feeds a regulatory submission, a financial statement, a payment, a safety decision or an executive metric. That is usually somewhere between 50 and 300 fields in a mid-sized company, out of tens of thousands.

In practice. Derive the list backward from consequence. Take the regulatory reports, the board pack and the top three operational processes, and trace which fields they depend on. That trace is your CDE list, and it comes with its own justification attached — which is what makes it fundable.

Where it goes wrong. Criticality is decided by asking each department which of their data is critical. Everyone answers "all of it", because nobody is rewarded for volunteering that their data does not matter. Criticality has to be derived from use, not collected from opinion.

The same customer appears three times with slightly different spellings, two addresses and one email between them. Deduplication finds those records, decides which belong together, and merges or links them so the business counts one customer instead of three. The hard part is not the matching algorithm; it is agreeing what makes two records the same entity, and which version of each attribute survives.

In practice. Profile the duplicate rate on the natural key of your most-used dataset before choosing a tool — the number makes the case on its own. Agree the matching rules and survivorship rules with the data owner, run deduplication as a recurring routine rather than a one-off cleanup, and declare the resulting record the source of truth. It is one of the more reliable early wins in a governance program because it is visible and measurable.

Where it goes wrong. A cleanup project deduplicates the customer base, everyone celebrates, and the source systems keep creating duplicates at the same rate. Six months later the count is back. Deduplication only stays fixed because of the governance decision that follows it: one authoritative source, and a process at the point of entry that checks before it creates.

A pipeline that crashes raises an alert. The expensive failures are the ones that do not: a table that loads half its usual rows, a feed that stops updating, an upstream column that changes type without notice. Observability watches for those signals continuously — row counts, freshness against schedule, schema drift, values drifting from their usual range — and tells someone when the data is behaving unlike itself.

In practice. Monitor the tables behind the decisions that matter first, and route every alert to a named steward, not a shared channel. Pair it with lineage, so an alert on a source table immediately shows which dashboards and models sit downstream. Observability is good at saying that something changed; deciding whether the change is a problem is still a job for someone who knows the business.

Where it goes wrong. A tool is switched on across the whole warehouse, learns thousands of baselines, and fires on every month-end spike and holiday dip. The team mutes it within weeks. The other failure is treating observability as a replacement for validation: it notices bad data after it has landed, which is useful, but it does not stop it getting in.

Profiling is how you find out that the country field contains 47 distinct spellings of "United Kingdom", that 8% of the birth dates are 01/01/1900, and that a column documented as mandatory is empty in a third of rows. It is the cheapest diagnostic in data work and the one most often skipped, because it produces uncomfortable facts before a project has agreed on its scope.

In practice. Profile before you promise. Half a day of profiling on the tables behind a proposed dashboard will tell you whether the dashboard is a two-week job or a two-quarter one, and that is the single most useful thing you can know at the start.

Where it goes wrong. Profiling output is presented raw. Nobody outside the data team has an opinion about a cardinality report. Translate it: "the customer table has 14,000 duplicate records, which is why the churn rate in the board pack is overstated by roughly four points." Same finding, different consequence.

There is no absolute data quality. A customer address that is good enough to send a marketing email is not good enough to ship a pallet, and the same record can be simultaneously acceptable and unusable depending on who picked it up. This is why "improve our data quality" is not actionable and "our address data must be good enough to deliver to, and today 12% of it is not" can.

In practice. Quality work runs in a loop: pick a use that matters, define the rule that use requires, measure the breach rate, fix the process that creates the breach, keep measuring. The fourth step is the one that changes anything — cleansing without fixing the source is a subscription, not a project.

Where it goes wrong. Quality is measured against every dimension for every field and reported as a single score. A composite percentage tells nobody what to do on Monday. Report by rule and by owner, name the process that produced the breach, and the conversation becomes fixable.

The dimensions exist so that "the data is bad" becomes a diagnosis. Completeness is whether the value is there. Validity is whether it conforms to its format. Accuracy is whether it matches reality — the only dimension that usually needs a human or an external reference to test. Consistency is whether the same fact agrees across systems. Timeliness is whether it arrived in time to be useful. Uniqueness is whether the entity appears once.

In practice. Most real problems are validity, completeness and consistency, in that order, because those are the three a system can create silently. Naming the dimension tells you where the fix belongs: validity is usually an input control, consistency is usually an integration, timeliness is usually a schedule.

Where it goes wrong. Accuracy gets measured with a rule, which it cannot be. A postal code that passes format validation and belongs to a different city is valid and wrong. Testing accuracy means comparing against something authoritative, and if no such source exists, say so instead of reporting 98%.

A rule has four parts: the data it applies to, the condition it asserts, the threshold at which the result counts as a failure, and the person who does something about it. Without the threshold, every rule is either always green or always red. Without the owner, a failing rule is a notification nobody has agreed to receive, which within a month is a filtered email folder.

In practice. The rules worth writing come from incidents. Something went wrong, somebody investigated, the cause was a data condition — encode that condition as a rule so the next occurrence is caught before the consequence. A backlog of rules derived from real incidents is credible in a way a generated rule set never is.

Where it goes wrong. Rules are generated automatically from profiling results and switched on in bulk. The result is thousands of alerts, most of them describing conditions that are perfectly normal in that business, and the team stops reading any of them. Alert fatigue is not a tuning problem, it is a design decision made too early.

A data quality SLA turns "the data should be good" into numbers somebody signs: the customer table lands by 06:00, mandatory fields are at least 99.5% populated, billing accuracy stays above an agreed line. It sits between the team that produces the data and the teams that build on it, and it names an owner on the producing side. Without that name it is a wish with a decimal point.

In practice. Start with three dimensions, usually freshness, completeness and accuracy, on the handful of datasets that feed decisions people actually argue about. Each commitment needs a measurement that runs automatically and a response time for breaches, not just a target. The useful SLA is the one a domain owner can see on a dashboard next to whether it was met last month.

Where it goes wrong. The SLA is written by the consuming side, promises what they would like rather than what the producer can deliver, and is breached from week one. Nobody renegotiates, everybody stops looking, and the document survives as evidence that quality was once discussed. An SLA that is never breached is usually set too low; one that is always breached is not an agreement.

A threshold is the number that turns a measurement into a decision. Completeness of 97% means nothing on its own; completeness below 98% on the billing address field, which stalls invoicing, means the steward gets a ticket. The data owner sets it, because only the business knows how much error a process can absorb before it costs money. Engineering then enforces it, and the steward handles what falls below it.

In practice. Set thresholds per use, not per field in the abstract, and start from the consequence: what breaks downstream, and at what rate does it start to hurt? Put the threshold where work already happens — in a pipeline's definition of done, in release criteria — so it is checked every time rather than reviewed once a quarter. Write down why each number was chosen; the reason is what lets someone change it later without a fight.

Where it goes wrong. Thresholds are copied from a vendor default or set to 100% because anything less sounds like accepting bad data. A threshold of 100% fires constantly, gets muted, and protects nothing. The opposite failure is a threshold set so loosely it never fires, which looks like good quality on the dashboard and is not.

Validation is the gate. At ingestion it enforces the schema, rejects negative transaction amounts and malformed emails, and checks that mandatory keys are populated. During transformation it checks that a return has a matching purchase and that totals reconcile between source and target. Records that fail are rejected or quarantined rather than passed along, because the cheapest place to fix bad data is before anything has been built on top of it.

In practice. Put the first checks at the points where unvalidated data currently enters: API ingestion and manual file uploads are the usual suspects. Start light — schema, completeness, a few range checks on high-priority tables — and add business-rule validation where incidents show you need it. A failed check should halt the load or route records to a quarantine table, and somebody should own what lands there.

Where it goes wrong. Checks log failures and let everything through, so validation becomes a report of what went wrong yesterday. Or the quarantine table exists and nobody looks at it, which is just a slower way of losing records. Validation without a decision about what happens on failure is monitoring with extra steps.

Data quality work fails in a predictable way: somebody runs a cleanup, the dashboard turns green, and six months later the same field is broken again because nothing upstream changed. DMAIC is the discipline that prevents that. It comes from manufacturing, it fits data almost unchanged, and its value is entirely in the last letter — Control is the step that separates an improvement from a cleanup.

In practice. Define picks one critical data element and the business pain attached to it, in money or in hours. Measure profiles the current state so there is a baseline, not an opinion. Analyze traces the defect to its origin, which is almost always a process or a form rather than a database. Improve fixes it where it starts — a required field, a validation, a changed handoff, a retrained team. Control leaves behind a quality rule, a monitor, a threshold and a named owner who gets the alert. One cycle per element, six to ten weeks, one page of evidence at each step.

Where it goes wrong. Teams stop after Improve, because that is where the visible win is and where the sponsor claps. The other version is a project that spends a quarter in Measure and Analyze, produces a beautiful root-cause deck, and never changes a system.

A broken field is a symptom. The cause is almost always upstream of the database: a form that accepts free text, a handover between teams that nobody owns, an integration that silently truncates, a target that rewards entering anything to close the ticket. Root cause analysis is the discipline of asking why until you reach something a person or a process change can fix. The 5 Whys is the usual tool and lineage is the map you follow. It is the Analyze step in DMAIC, and the step that turns a cleanup into an improvement.

In practice. Start from the escalations, not from a framework. Pull a year of incidents, tickets and audit findings and code them by cause; most organizations find that four or five causes account for the majority, and that at least one has been recurring for years without an owner. Each confirmed cause should end in two things: a fix where the defect originates, and a data quality rule that catches the next occurrence.

Where it goes wrong. The analysis stops at the first technical answer — "the ETL job failed" — which is where blame is easiest to place and least useful. Or it runs for a quarter, produces a beautiful cause-and-effect diagram and changes no system. An analysis that does not change a process has only documented the problem more thoroughly.

Every organization has them: the export that finance re-keys every month, the regional workbook with its own definition of "active customer", the file the analyst trusts more than the dashboard. Each one started as a reasonable workaround for a real problem — slow access, a wrong number, a report that did not answer the question. Together they are where the organization's actual numbers live, outside any control, lineage or audit.

In practice. Treat shadow spreadsheets as evidence, not misconduct. Ask what each one fixes, and you have a ranked list of data pain points: missing definitions, access that takes three weeks, quality nobody escalates. Counting them is a reasonable proxy for the trust gap. Retire them by fixing the reason they exist and giving consumers a route to report discrepancies to a steward, then measure how many go away.

Where it goes wrong. Governance bans spreadsheets or locks down exports without fixing what drove people to them. The work moves somewhere less visible, the risk is relocated rather than reduced, and the next audit finds the same numbers in a personal drive. A spreadsheet nobody needs anymore disappears on its own.

Change management is the part of governance that deals with people rather than data. Governance redistributes authority, adds routines and asks people to stop doing things that work for them locally, such as exporting raw files into their own spreadsheets. Resistance to that is normal, and it usually has ordinary causes: people do not know what is changing, they fear losing control of their own numbers, or they see friction with no benefit to them. The DMBOK gives the topic its final chapter, which is roughly where most programs leave it too.

In practice. Open with a business story, not a policy: the forecast that was wrong, the campaign that went out late. Recruit champions inside the domains, stewards and team leads the rest of the team already listens to, because peers persuade where a central team cannot. Translate jargon into plain sentences, make early wins visible, and measure adoption: how many people use certified datasets each week, and how many shadow spreadsheets have been retired.

Where it goes wrong. It gets treated as communications: a launch email, a policy PDF, a slide at the town hall. Everyone is informed and nobody behaves differently. Counting published policies measures how much was written. It tells you nothing about whether anyone changed what they do.

Culture is observable in small behaviors. Whether a meeting starts with the number or with the opinion. Whether an analyst can say the data does not support the plan without a career cost. Whether a report that shows a failure gets circulated or gets revised. Whether people go looking for existing data before commissioning new. None of that comes from a poster; all of it comes from what senior people are seen to do when the data is inconvenient.

In practice. Culture moves when the incentives move. The most effective single intervention is a leader publicly changing a decision because of evidence, and saying that is why. That is worth more than a year of communications.

Where it goes wrong. Culture is treated as the program's soft, unmeasurable component and handed to communications. It is neither soft nor unmeasurable: count how often the numbers in a decision paper are reconciled beforehand, how many decisions cite a source, how long it takes to answer "where did this come from". Those move, and they can be tracked.

The opposite of data tyranny, the state where a routine question needs a ticket, a week and written permission from IT. Democratization moves the default from "locked unless approved" to "available unless risky", with ownership pushed out to the business domains and a central function that sets security standards, maintains the glossary and keeps the architecture coherent. It is not an ungoverned free-for-all. Done properly, it takes more governance than the lockdown did, just of a different kind.

In practice. Tier the data. Highly restricted data — PII, financial ledgers, trade secrets — keeps strict approvals, masking and audit logging. Operational business data is open to authenticated users through certified models. Raw exploratory data lives in sandboxes. Add a catalog so people can find things, role-based provisioning so access does not depend on somebody's inbox, and literacy training so access turns into decisions.

Where it goes wrong. It is announced as a value and delivered as a licence: everybody gets the BI tool, nobody gets definitions or certified data. Or the restrictions stay, people route around them, and the organization ends up with a data black market of exported spreadsheets — democratization, technically, with none of the controls.

Data literacy is not statistics. It is the working capability to look at a chart and know what question it answers, to notice that the denominator changed, to ask where a number came from before repeating it, and to say "this does not support that conclusion" in a meeting. Most of it is skepticism and vocabulary rather than technique, which is why it can be taught to a commercial team in weeks and why a tool rollout never produces it.

In practice. Literacy is built on the organization's own data, in the context of decisions people already make. A one-hour session that walks a sales team through their own pipeline report — what each field means, where it breaks, which comparisons are invalid — outperforms a generic course by a wide margin.

Where it goes wrong. Literacy is bought as a license for an e-learning platform and reported as completion rates. Completion measures attendance, not capability. The measure that matters is whether the questions asked in review meetings get better, and that is observable within a quarter if anyone is watching for it.

The test is not whether data appears in the decision paper. It is whether the data could have produced a different decision. An organization that assembles evidence after choosing is not data-driven, it is data-decorated, and everybody involved knows the difference. Being genuinely data-driven also requires accepting that some decisions have insufficient evidence and saying so, rather than dressing a judgment call as an analysis.

In practice. Write down, before the analysis, what result would change your mind. That single habit converts a confirmation exercise into a decision, and it is free.

Where it goes wrong. The phrase is used to mean "we have dashboards". Dashboards are supply. A decision-making culture is demand, and the two are independent — plenty of organizations have excellent reporting that no decision has ever depended on. Governance work that only improves supply will not move this at all.

Self-service analytics replaces the ticket queue with infrastructure: a searchable catalog to find data, access provisioned by role rather than by email thread, certified datasets to build on, and BI tools business people can actually use. The point is speed to an answer for the routine question — the store manager checking local stock, the marketing analyst slicing last month's campaign — while the central team stops being the bottleneck for every report change and starts maintaining the things everyone else builds on.

In practice. It works on top of governance, not instead of it. The minimum is a small set of certified datasets with a named owner, agreed definitions for the metrics people will compute, and access tiers that let most users into aggregated operational data without an approval each time. Then training on the users' own data, because a tool nobody can interpret just produces confident wrong numbers faster.

Where it goes wrong. The tool is rolled out before any of that. Every department builds its own dashboards with its own formula for the same metric, the reports multiply, and within a year the leadership meeting has three revenue figures and trusts none of them. That is not a failure of self-service. It is self-service without a glossary.

An operating model has four parts: the domains and their owners, the roles and how much time each carries, the forums and what each one decides, and the routes — how a definition gets changed, how an issue gets escalated, how an exception gets approved. It also declares a shape: centralized, federated, or a hub with domain teams. Federated is the most common answer and the least often specified, which is why it so often means nobody.

In practice. Fit the model to the organization you actually have. A company that runs everything through functional heads will not sustain a domain-based model, no matter how correct the domain map is. Governance that fights the existing decision structure loses.

Where it goes wrong. The model is designed for the end state and launched all at once — every domain, every role, every forum, on the same date. Capacity does not exist, the forums do not fill, and eighteen months later the model is a document that describes a thing that never happened. Two domains done properly beats twelve announced.

Maturity is a statement about repeatability, not about tooling. An organization where the monthly report is correct because a specific analyst knows which three columns to ignore is immature regardless of its technology budget. One where the same report is produced correctly by whoever is on duty, with the exceptions documented, is mature. The distinction is whether knowledge lives in people or in the process.

In practice. Maturity is worth assessing per capability, not as one number. You can be genuinely strong on metadata and weak on quality, and the average of the two tells you nothing you can act on. Assess the capabilities, pick the two that block the nearest business outcome, and leave the rest.

Where it goes wrong. Maturity becomes the goal. Nobody has ever received budget for moving from 2.1 to 2.6; they receive budget for closing a regulatory finding or unblocking a launch, and maturity improves as a by-product. Present the assessment as a diagnosis, never as an objective.

The model is the ruler; the assessment is the act of measuring with it. You pick a framework, gather evidence across its dimensions — quality, stewardship, metadata, security, architecture — and map each one to a level, so the result reads "level 1 on quality, level 3 on security" rather than a single grade. The useful version has four moves: scope it, gather evidence, map the levels, and turn the gaps into a plan with owners and dates. It is a baseline you repeat, not a certificate you frame.

In practice. Evidence beats questionnaires. Ask to see the glossary, the last few incident tickets, the access approval trail, and score what is shown rather than what is described. Keep the scope to questions you will act on: a quick read to find your weakest dimension is useful, a forty-item scored baseline across every knowledge area is a project in itself. And you do not need one to find pain — interviews and a year of escalations will surface that faster.

Where it goes wrong. The assessment becomes the program's first six months and its only deliverable. Or the target gets written as a level, "reach level 3", which nobody outside the data team can evaluate and no budget review will fund. Translate each gap into a business result before it goes on the roadmap.

Most models share a five-level shape: nothing deliberate is happening, some people do it well, it is documented and repeatable, it is measured, it is improved on purpose. The value is not the score but the vocabulary — a model gives a leadership team a shared way to say "we are at level 1 on quality and level 3 on access control", which is a much more productive conversation than trading anecdotes.

In practice. Use the model as an interview guide, not a questionnaire. The evidence that determines a level is what someone shows you: the actual glossary, the last three incident records, the approval trail for a definition change. Self-assessment inflates by roughly a level in every organization.

Where it goes wrong. The output is a radar chart, and the radar chart is the deliverable. A maturity assessment that does not end with three named actions, an owner each and a date has produced a diagnosis nobody can act on. The chart is the beginning of the conversation, not its conclusion.

DCAM is published by the EDM Council (Enterprise Data Management Council), an industry association with deep roots in financial services, and it shows: it is built for organizations that will one day have to show an auditor or a regulator how their data is managed. It groups data management into eight capability areas — strategy and business case, program and funding, business and technical architecture, data quality, governance, the control environment and analytics — and scores each against six realization levels, from not initiated to enhanced. Where DAMA-DMBOK describes what data management covers, DCAM is designed to measure how far along you are.

In practice. Its strength is evidence. A DCAM score is meant to rest on artefacts — the approved policy, the funded role, the control that runs — which suits it to results that must survive an audit or be compared across business units. It is also detailed, and full use generally runs through the Council's membership and training. Most smaller programs borrow its structure rather than running it end to end.

Where it goes wrong. DCAM is chosen because it sounds rigorous, then run as a self-scored spreadsheet by the team being assessed. The detail that makes it credible becomes the reason it never finishes. If nobody outside the data office will look at the scores, a lighter model and three named actions will do more.

Every maturity model borrows the same ladder from CMMI, whatever it calls the rungs. Level 1 is ad hoc: it works because a particular person is still employed. Level 2 is repeatable: the same thing happens twice for the same reason, usually inside one team. Level 3 is defined: it is written down, owned, and the same across domains. Level 4 is managed: it is measured, and the measurement is used to make decisions. Level 5 is optimized: it improves on purpose, on a cadence, without a program pushing it. Notice that none of those sentences mentions a tool.

In practice. Score each capability separately — metadata, quality, privacy, literacy, architecture — and expect an uneven profile. Level 3 in classification and level 1 in quality is not a contradiction; it is your roadmap, and it tells you what the next twelve months should buy. The useful conversation is never "what level are we", it is "what specifically would have to be true for this capability to be a 3, and is that worth doing this year".

Where it goes wrong. The level becomes a target instead of a description. Someone commits to "level 4 by December", the assessment quietly turns into a self-graded exam, and the program starts optimizing the score rather than the business. Level 5 everywhere is also the wrong ambition: most organizations should be deliberately level 2 in the domains where nothing much is at stake.

Proactive governance means the controls sit where the data is made, not where it is consumed. Definitions are agreed before the table is built. Quality rules run inside the pipeline, so a bad load stops instead of arriving. Interfaces carry a contract, so a breaking change fails the producer's build rather than someone's Monday report. Access is reviewed on a schedule rather than when an auditor asks. Classification happens at creation, when the person who knows what the field contains is still in the room.

In practice. It changes what you report. A reactive program counts incidents closed; a proactive one counts things that never happened — loads blocked before publishing, breaking changes caught in CI, access removed on the day someone changed roles, new datasets that arrived with an owner and a classification already attached. Those are leading indicators, they are dull, and they are the only evidence that prevention is working.

Where it goes wrong. Prevention curdles into gatekeeping. Every new dataset needs three approvals and a two-week wait, so teams do what people always do when the front door is slow: they build the thing in a spreadsheet, a personal cloud account or a shadow warehouse, and the governance function loses sight of exactly the data it was trying to protect. If a control cannot be automated, it needs a service level — and if it has neither, it is a queue, not a control.

You can spot it from the calendar. Work arrives as incidents: the regulator asks a question, finance finds two revenue figures, a customer receives someone else's statement, a model is caught training on data it should never have seen. The team responds well — often heroically — and then returns to whatever it was doing until the next one. Reactive governance is not a character flaw. It is what governance looks like before anyone has funded prevention, and almost every program starts here.

In practice. The way out is to use the incidents rather than just survive them. Log each one with what it cost, what data was involved and which control would have caught it. Twelve entries make a pattern, and a pattern makes the business case that a maturity slide never will: the same three domains, the same missing owner, the same absent quality rule. That is also the moment to convert one incident into a permanent control instead of a cleanup.

Where it goes wrong. Staying here. A team known for fixing things becomes a cleanup crew — valued, busy, never funded to prevent anything — and the reputation hardens: governance is the people you call after the damage. Watch for the tell that this is happening, which is that nobody can name a decision the governance function made before an incident forced it.

TDWI, the data and analytics research and education organization, describes analytics maturity as five stages that most organizations recognize in themselves on first reading. Nascent: data use is ad hoc and individual, and reporting is manual. Emerging: leadership starts asking for evidence, and definitions are inconsistent in a way everyone knows about. Developing: training is formalized and data is consulted routinely in operational decisions. Mature: fluency reaches well beyond the technical teams and standard definitions are the default. Leading: evidence is expected, and analytics is a competitive input rather than a support function. It looks at analytics as a whole — organization, infrastructure, data management, analytics and governance — rather than at governance alone.

In practice. Use it for the conversation about how decisions get made, where a governance-only model would miss the point; it pairs naturally with literacy and culture work. The stage descriptions are short enough to read out in a leadership meeting, and people place themselves quickly, usually more generously than the evidence supports.

Where it goes wrong. The stage label becomes the objective. "Move from developing to mature" is not a business outcome and will not survive a budget review. "Cut the competing revenue definitions from four to one" is the same progress in a form someone will fund. The stage is a diagnostic, not a destination.

AI governance asks what a model was trained on, whether that data was permitted for the purpose, who approved deployment, what the model is monitored for, and who can switch it off. Four of those five questions are answered by data lineage, classification, consent records and ownership. That is why an organization with no data governance cannot have AI governance: there is nothing underneath it to appeal to.

In practice. The fastest route to defensible AI governance is to extend what exists. Add "approved for model training" to the classification scheme, require lineage for training datasets, put model approval on the existing council agenda, and log the decision. That is weeks of work rather than a new program.

Where it goes wrong. AI governance is built as a parallel structure with its own committee, policy set and vocabulary. Within a year it has a different owner and a different answer for the same dataset, and the first regulatory question exposes the gap. One set of decision rights over data, extended to models, is the arrangement that holds.

Confidential is the level where the company is the one at risk. If it leaks, a competitor prices against you, a negotiation collapses, a valuation moves, or your own people find out what each other earn. That is a real harm and it deserves real controls — but it is a commercial harm, which is why it sits on a different track from sensitive personal data, where a person is the one exposed.

In practice. The label is worthless on its own; what makes it useful is the handling rules stapled to it. Who approves access, and for how long. Where it may live — which platform, which region, which tenant. Whether it can leave the company at all, and under what agreement. How long it is kept and what happens at the end. Whether it may be pasted into an external AI tool, which is now the question this classification gets asked most often. If a level has no rules attached, it is decoration.

Where it goes wrong. Everything becomes confidential. A default of "restrict it, to be safe" produces a warehouse where 90% of tables carry the top label, so people route around the controls to do their jobs and the label stops carrying information. A workable classification is deliberately lopsided: most data is internal, a slice is confidential, a small set is restricted, and someone senior is willing to defend where the lines fall.

A classification scheme is a small set of labels — public, internal, confidential, restricted is the common four — each attached to concrete handling rules: who may access it, whether it may leave the country, whether it may be used to train a model, how long it is kept, how it must be destroyed. The label is only worth having because of the rules behind it; a label with no consequence is decoration.

In practice. Four levels is the practical maximum. Every level beyond that produces edge-case arguments and inconsistent tagging, and the difference between "confidential" and "highly confidential" is almost never operationalized differently anyway.

Where it goes wrong. Classification is applied by asking data owners to tag everything, which yields the whole estate marked confidential — the safe answer for the person tagging, and useless for everyone else. Anchor the scheme in examples, default to internal, and require a justification for the top level.

Privacy is about the person in the data, not the organization holding it. Security asks whether the data is protected from people who should not see it. Privacy asks whether the people who can see it should be using it for this. Regulations such as GDPR, LGPD and CCPA turn that question into obligations: a legal basis, a declared purpose, minimization, retention limits and rights the person can exercise.

In practice. Privacy connects to classification and access. Personal fields are tagged where they are created, masked by default, and released for a stated purpose rather than for a job title. Purpose tagging does most of the work: a dataset collected for billing does not automatically become available for a churn model, and a training set inherits the consent and purpose limits of every source that fed it.

Where it goes wrong. Privacy is handled as a legal document instead of a set of controls. The policy says data is used only for declared purposes; nothing in the catalog records what those purposes were. Then a model goes into production and nobody can say whether the customers in it consented to this use. The policy was never wrong. It just had nothing underneath it.

Data is created, used, goes stale, and should eventually be archived or deleted. Retention is the decision about when. A usable retention rule has three parts: the class of data it covers, a period, and a trigger — the event that starts the clock, such as the end of a contract or the closing of an account. A period without a trigger is a number nobody can apply.

In practice. Setting the rule is governance: the owner, with legal and privacy, decides how long customer records are kept and what counts as the end of the relationship. Implementing it is management: the retention job that moves records to archive on the legal schedule and deletes them on time, plus evidence that it ran. Retention also flows downstream. Copies, extracts and training sets inherit the rule of their source, or the rule means very little.

Where it goes wrong. Retention is the governance decision most programs defer indefinitely, because keeping everything feels safe and deleting anything feels risky. That is how organizations end up holding personal data for a decade with no defensible basis, and discovering it during an audit or a breach rather than a review.

Two people run the same query against the same table and get different answers, on purpose. The support agent sees a card number ending in 4471 and the rest as asterisks; the fraud analyst sees all of it; the data scientist sees a consistent hash that still joins but identifies nobody. Nothing was copied and nothing was destroyed — the policy is evaluated as the query runs. That is what makes it different from static masking, which produces a separate, permanently scrambled copy for lower environments.

In practice. The rule is attached to the classification, not to the team: a column tagged as personal or sensitive inherits a masking policy, and roles are granted the right to see through it. Snowflake, BigQuery, Databricks and SQL Server all support this natively, which means you write the policy once instead of maintaining a hand-built view per audience — and views built by hand are how an unmasked column reaches a dashboard nobody remembers creating.

Where it goes wrong. Masking is treated as the whole control. A masked identifier next to an unmasked date of birth, postcode and transaction amount re-identifies people comfortably, so masking without thinking about what the remaining columns reveal is theatre. The other classic: production is masked properly and the test environment holds a two-year-old unmasked copy that half the company can read.

PII is broader than most inventories assume, because identifiability is contextual. A postal code is not identifying; a postal code plus a birth date plus a job title frequently is. Under GDPR the relevant concept is personal data, which covers anything relating to an identifiable person, including data that identifies them only when joined to something else you hold. This is why "we removed the names" is not, by itself, anonymization.

In practice. Find personal data by tracing purpose rather than scanning columns. Ask which processes involve a person, what was collected, what the person was told at the time, and what basis the organization is relying on. Pattern-matching scanners find email addresses; they do not find the join that makes a dataset re-identifiable.

Where it goes wrong. Pseudonymized data is treated as anonymous and moved outside its original controls — into an analytics environment, a test system, a training set. Pseudonymized data is still personal data, because the key that reverses it exists. Anonymous means irreversibly so, and very little data in an operational estate meets that bar.

RBAC is a governance idea before it is a technical one. Permissions attach to a role — claims adjuster, credit analyst, marketing analyst — the data owner approves what that role may see, and a person receives access by being placed in it. The gain is not fewer clicks; it is that the question changes from "why does Marta have this?" to "should a credit analyst see this?", which is a question someone can actually answer, and answer once for everybody.

In practice. Roles are named after jobs, never after people or projects. The data owner approves the role's scope, and access is joined to the HR lifecycle: new starters inherit their role, movers lose the old one on the day they move, and leavers are cut automatically. Sensitive columns stay behind a masking policy even inside an approved role, and every role is recertified on a schedule by the owner who granted it — recertification being the part everybody buys the tool for and nobody runs.

Where it goes wrong. Role explosion. Every exception becomes a new role, and after two years there are more roles than employees and no one can say what any of them means, which is functionally the same as having no model at all. The second failure is movers: joiners and leavers get handled, but the person who has changed jobs three times keeps the union of everything they have ever needed. When roles alone cannot express the rule, the answer is usually attributes — region, purpose, classification — layered on top, not another hundred roles.

The distinction that matters is who gets hurt. Sensitive data is the category where the damage lands on a human being: a diagnosis, a biometric template, religious or political affiliation, union membership, sexual orientation, ethnicity, a criminal record, an address someone is hiding at. GDPR calls these special categories, Brazil's LGPD calls them dados sensíveis, and both treat them as a separate class with a stricter legal basis — because the consequence of a leak is not embarrassment or a fine, it is discrimination, exclusion, or physical risk to a person who never chose to be in your database.

In practice. It is a tag at column level, applied when the data is created and inherited by everything downstream, with masking on by default and access granted for a stated purpose rather than a job title. Retention is shorter, third-party sharing needs a named legal basis, and models trained on it inherit every one of those constraints. The honest first step is usually smaller than a policy: find out which tables actually hold it, because the inventory is almost always wrong.

Where it goes wrong. It gets confused with confidential data, and the two are governed as one. Salaries and pricing are confidential — the company is exposed. Health records are sensitive — the individual is exposed. Collapsing them means either protecting commercial data as if lives depended on it, or protecting people's health data with the care you give a price list. Second failure: the tag lives on the source column and the copy in someone's spreadsheet inherits nothing.

Data architecture is the blueprint for the estate: the models, the integration patterns, the platforms and the paths data takes between them. In DMBOK it is one of the knowledge areas around the governance hub, and the division of labor is clean. Governance supplies domain boundaries, the authoritative source for each entity, and the standards. Architecture turns those decisions into models and platform design. It is data management work, not governance work, but it is where governance decisions become physical.

In practice. The architecture questions that matter most to governance are rarely about technology. Which system is authoritative for customer? Where does a domain end? Which standard does a new pipeline have to meet before it ships? If those answers exist and are written down, the architects can make good choices quickly. If not, they make the governance decisions themselves, implicitly, one integration at a time.

Where it goes wrong. Years of reasonable local choices produce a fragmented estate: legacy mainframes, a cloud lakehouse and a dozen SaaS tools, each with its own overlapping definition of the same entity. Nobody designed the mess. Each piece was sensible when it was added, and no decision ever covered how they fit together. A platform migration does not fix that, because the definitions move across with the data.

Most data incidents are not corruption, they are surprise. An engineer renames a column, tightens a type, changes what "cancelled" means, or drops a nightly load to hourly — all reasonable changes — and eleven dashboards and two models downstream break, or worse, keep working and quietly report something else. A data contract makes the promise explicit so the change becomes a negotiation instead of an outage: this is the schema, this is what each field means, this is how fresh it will be, these are the quality thresholds, this is the owner, and this is how much notice you get before any of it changes.

In practice. The contract lives with the producer's code, in version control, and it is tested. A breaking change fails the producer's pipeline before it ships, which is the entire point — the cost of the change lands on the team making it rather than on whoever notices first. Consumers register against it, so the producer can see who they would break and deprecation means a date and a migration path rather than an announcement. On a marketplace listing, the contract is what turns a table into something another team can build on.

Where it goes wrong. The contract is a page on the wiki. Nothing checks it, it drifts within a month, and it becomes documentation of how the data used to behave. The other failure is over-promising: freshness or completeness the producer has no way to guarantee, so the contract is breached constantly and everyone stops reading the alerts.

A domain is how governance is cut into pieces small enough to own. Customer, product, supplier, employee, finance, contract: each is a body of data with its own definitions, its own systems of record, its own regulatory exposure and its own natural owner somewhere in the business. Domains are the unit almost every operating model is built on, because "who owns the data" is an unanswerable question and "who owns customer data" is not.

In practice. Good domains follow the business, not the org chart or the database. They are few — eight to fifteen at enterprise scale — and each has exactly one accountable owner, a system of record, and a list of critical data elements. The test of a boundary is whether a disputed field has an obvious home.

Where it goes wrong. Domains get drawn around systems, so "Salesforce data" becomes a domain and the customer record that also lives in billing and support has three owners and no owner. They also get drawn too small: forty domains means forty owners, which means no one is meaningfully accountable and the council cannot fit in a room.

A data lake accepts almost anything: application exports, logs, IoT feeds, SaaS extracts, files nobody remembers requesting. Unlike a warehouse, it does not require a schema up front, which makes it cheap to fill and flexible to use. A lakehouse adds warehouse-style tables and controls on top of the same storage. Either way, the lake solves a storage problem. It does not, by itself, solve any problem of meaning, ownership or trust.

In practice. A governed lake looks boring. Each zone or dataset has a named owner, a classification and an entry in the catalog. Raw landing data is kept apart from curated data that people are allowed to report on, and the difference is visible to whoever is browsing. Sensitive columns are masked by default, not after the first complaint.

Where it goes wrong. Ingestion runs unmanaged and everything goes in, because it is easy. Within a couple of years the lake holds duplicate records, three versions of the customer table and a storage bill nobody can explain, and analysts quietly go back to their spreadsheets. That is the data swamp, and it is a governance outcome, not a technology one: nobody decided what belonged there or who answered for it.

A pipeline is the plumbing between a source system and a report, a model or another system: ingest, validate, transform, load, repeat on a schedule. Building and running pipelines is data management work. Governance does not write them, but it decides what they must respect: which source is authoritative, which fields are classified, what quality tolerance applies, and who gets told when something upstream changes.

In practice. The dangerous failure is rarely the crash. A pipeline that stops raises an alert and someone fixes it by lunchtime. The one that keeps running with a null in the wrong place or a mismatched currency code quietly turns a bad record into a bad aggregate into a bad decision. Checks belong at every critical stage, not just at the end, and a failed check on critical data should halt the run or send the records to quarantine rather than let them through with a warning.

Where it goes wrong. Every team builds its own pipeline from the same source, each with slightly different logic, and nobody owns the differences. Then an upstream schema changes without notice, half the pipelines break silently, and the discrepancy is found by an auditor. Fixing the pipeline is management. Deciding who must be told before the schema changes is governance.

Treating data as a product means somebody is accountable for its consumers being satisfied, not merely for the pipeline running. That implies documentation, a stable interface, a declared refresh frequency, quality guarantees, a way to report a problem, and a plan for changing it without breaking downstream users. It is the same discipline a software team applies to an API, applied to a table.

In practice. A data product is only a product if it has named consumers. Two teams that depend on it, with an agreed refresh and a route to complain, is enough. Without consumers you have a dataset with extra paperwork.

Where it goes wrong. Every existing table gets relabeled a data product with no change in ownership, documentation or commitment. Renaming does not create accountability. The test is simple and unforgiving: if the load fails on a Sunday, does somebody who is not the platform team know, care, and have a stated obligation to respond?

A silo forms when getting shared information centrally was, at some point, harder than rebuilding it locally. Sales has its customer list, finance has another, the warehouse team has a third. Nobody set out to create one; each was a reasonable shortcut. The visible cost is duplicated effort. The expensive cost is that the copies diverge, three dashboards show three answers to the same question, and nobody can say which one is right.

In practice. The governance response is not "consolidate everything" — that is a multi-year platform program, not a governance act. It is to name the authoritative source for each shared entity, declare the other copies derived, and publish that decision somewhere people will actually find it. A data catalog helps. The decision matters more than the tool.

Where it goes wrong. Silos are treated as a technology problem and answered with a migration. The data moves to one platform, the definitions move with it unchanged, and the organization now has the same silos in a single, more expensive location. A silo is ended by a decision about authority, not by a change of address.

A domain is where accountability sits; a subdomain is where the work actually fits in someone's head. Customer is a domain, and it is far too big for one glossary — prospects, consent and preferences, complaints, credit standing and loyalty each have different definitions of "active", different rules, different systems and different people who care. Splitting Customer into subdomains lets each of those be owned properly without inventing five new domains and five new owners on the org chart.

In practice. You know you need one when a single steward cannot answer questions across the domain, or when the same word needs two definitions inside it. A subdomain gets a named steward, its own entries in the business glossary, its own critical data elements and quality rules, and it is usually the unit that data products are actually built and published from. The domain owner still owns the whole; the subdomain steward runs a part of it.

Where it goes wrong. Subdividing until the catalog is a copy of the reporting structure. Fifty subdomains means fifty half-maintained glossaries, and the reorganization that arrives next year invalidates all of them. Split when a definition or an owner forces you to, not to make the diagram look complete.

Two directions, one set of governance questions. Inbound, you are buying: demographics, firmographics, credit scores, geospatial, weather, market feeds, whether through a broker or a platform exchange like Snowflake Marketplace or AWS Data Exchange. Outbound, you are publishing — sharing with partners, or selling an aggregate that only your company can produce. In both cases data crosses the boundary where your controls end and a contract takes over.

In practice. Inbound data gets the same treatment as internal data plus a licence: a named internal owner, a documented provenance, quality checks on arrival, and explicit terms on what you may do with it — whether it may train a model, whether it may be redistributed to a client, what happens to derived data when the subscription ends. Outbound goes nowhere without the DPO and legal on the record: what legal basis covers the sharing, what aggregation or anonymization is applied, and who is accountable when a partner uses it beyond the agreement.

Where it goes wrong. A purchased file arrives on a credit card, gets joined into production, and eighteen months later nobody can name its source, its licence or whether the contract still exists — but three regulatory reports depend on it. On the outbound side, the deal is agreed commercially and the privacy review happens after the first delivery, which is the expensive order to do it in.

A catalog tells you the data exists. A marketplace lets you get it. The difference is the checkout: a listing you can request, an approval that routes to the person accountable for it, and access that appears in hours rather than after a quarter of emails. It matters because the alternative is not "people wait" — it is that an analyst who cannot get the certified dataset in a reasonable time rebuilds it badly from a source extract, and now the company has two versions of revenue.

In practice. Every listing is a data product, not a table: it has an owner, a description in business language, a contract covering schema and freshness, a visible quality score, usage and cost figures, and a request flow that ends in a granted role rather than a ticket. Consumers can see who else uses it and what changed last month. The measure of whether it works is the median time from request to access, and whether the number is on someone's objectives.

Where it goes wrong. The marketplace launches with the entire warehouse dumped into it — ten thousand tables, no owners, no contracts — and it becomes a slower search bar. Or the storefront is real but the request routes into a queue with no service level, which teaches everyone the shortcut is faster. A marketplace with fifty genuinely owned products beats one with everything and nobody behind it.

Usefully understood, this is not one system holding all data. It is a per-attribute decision: the HR system is authoritative for employment status, the CRM for contact preferences, the ERP for the invoiced amount. Everywhere else may hold a copy, but nowhere else may disagree and win. Written down attribute by attribute, this is one of the most valuable artifacts a governance program produces.

In practice. Declare the authoritative source for the twenty attributes that appear in disputed reports, and require downstream systems to reconcile against them. That is a governance decision with a technical consequence, in that order.

Where it goes wrong. The phrase becomes a justification for consolidating everything into one platform, which is a multi-year program with a poor record. You do not need one system; you need one answer per attribute. Those are very different budgets, and only the second one actually resolves the argument in the meeting.