On-Demand Webinar · 1 hr 2 min

Redefining Data Governance with DataGovOps

Laura Madsen, author of Disrupting Data Governance, and Chris Bergh on why command-and-control data governance fails the way modern data teams work, and what DataGovOps puts in its place. Recorded July 2020; updated August 2026.

Presented by Chris Bergh

What you'll learn 6 points
  • Data governance historically claimed data usage and quality, compliance and risk, and security and protection. This session argues governance actually lives in a narrower place, and proposes a weighting: 40 percent increasing usage of data, 25 percent data quality, 25 percent data management including lineage, and 10 percent data protection.
  • DataGovOps is data governance done with DataOps practice: business glossary and data catalog as code, process lineage, automated data testing, self-service sandboxes with test data management, and agility in defined roles and responsibilities.
  • Deploy data catalog and glossary changes simultaneously with the code, model, and report changes that caused them, rather than updating the catalog after the fact.
  • Process lineage means keeping every version of the end-to-end process in a git repository and storing the as-run version — source code, test results, timing data — so the exact path the data took to value can be reconstructed.
  • Deming's finding that 94 percent of causes are common cause is the argument for governing the process rather than looking for a person to blame.
  • Automated production testing for governance spans five test types: traditional data quality, statistical process control, location balance, historic balance, and business-based tests.

Prefer to read it? The written version is in Continuous Governance with DataGovOps.

Slides

20 slides

Questions from this session

What is DataGovOps?

DataGovOps is what data governance looks like when DataOps practice is applied to it. Where a governance program produces a business glossary, data catalog, lineage, data quality definitions, security, and defined roles, DataGovOps produces the same things as running machinery: glossary and catalog as code, process lineage captured from real runs, automated data testing, self-service sandboxes with test data management, and roles that can change without a committee.

How is DataGovOps different from traditional data governance?

Traditional governance documents intent; DataGovOps automates and verifies it. A catalog maintained by hand drifts from the pipelines it describes. A catalog deployed as code alongside the schema, model, and report changes cannot drift, because the same deployment that changes the data changes its description.

Where should a data governance program spend its effort?

This session proposes weighting governance toward use rather than control: 40 percent on increasing usage of data, 25 percent on data quality, 25 percent on data management such as lineage, and 10 percent on data protection. The point of the rebalance is that governance justified only by risk reduction tends to be experienced as a tax, while governance that measurably increases data usage pays for itself.

What kinds of automated tests support governance?

Five types are named: traditional data quality checks, statistical process control, location balance tests, historic balance tests, and business-based tests. They are meant to run automatically in production, across the whole tool chain rather than one tool, sending alerts and keeping history so trends are visible.

Why does DataOps claim how you work matters more than what you build?

Because most failure is systemic rather than individual. Deming found 94 percent of causes were common cause — properties of the process, not of the person who happened to be on shift. A team that responds to each error by finding someone to blame keeps the process that produced the error, and so keeps the errors.

Where to go next