Governance and Operations
The OS that keeps BI trustworthy
Governance is the operating system that keeps BI trustworthy: owners, controls, SLAs, incident management and release discipline — a system where 'who can change this and why' is always answerable.
What you will learn
- Design ownership (RACI) and change controls
- Run SLAs, incidents and releases operationally
- Keep governance light enough to survive contact
What is this?
Governance and operations is the system around the numbers: every report/metric has an owner and change controls; pipelines have SLAs; incidents have a path (detected, triaged, communicated, fixed); releases move through review. Done right it's almost invisible — trust is the product — done wrong it's either absent (chaos) or so heavy the analysts revolt. The craft is weighing controls against velocity.
Why do you need it?
- Without ownership, red lights die unanswered.
- Controls exist so a definition change can't silently move executive numbers.
- Incident discipline is what makes a pipeline failure a boring fix, not a scandal.
- Ops maturity is how BI earns its seat at the governance table.
Mental model
An airline's dispatch and maintenance log
BI governance
No flight departs without a dispatch release and a signed maintenance log; the process exists to make safety routine, not bureaucratic. BI governance is the flight log: who cleared the release, when the metric last refreshed, who owns a red flag. The log is boring — exactly its virtue.
How it works
- Responsibilities: RACI per artifact — owner, contributor, approver, consulted.
- Controls: change gating on definitions; review before promotion.
- Operational commitments: refresh SLA, freshness thresholds, error budgets.
- Incidents: triage path, blameless communication, fix + prevent-the-class.
- Release: small batches, review, rollback story, changelog — public.
The governance operating loop.
Examples
The governance one-pager
ARTIFACT OWNER APPROVER CONTROLSdaily_orders orders-analytics flow-lead review+CIrevenue model finance-analytics finance-lead signed gatechurn_score (v2.1) retention-analytics CSO model review SLAs: daily by 06:00 UTC, freshness < 24h, error budget 2%INCIDENT (2026-02-11) orders stale -> triaged 09:00, communicated 09:12, fixed 10:45, prevention: alert addedRELEASE: weekly, small batches, rollback story, public log.Owners, controls, SLAs, incident trace and release rhythm — governance as a boring, working system.
In production
- A RACI row per dashboard, so 'who owns this number' has a URL.
- Freshness SLA page the on-call; the incident post-mortem owns the fix class.
- Weekly release with a public changelog; rollback rehearsed on a staging pull.
Best practices
- One owner per artifact, one approver, everyone else consulted not blocking.
- Controls scale with consequence: definition changes gated, cosmetic changes free.
- Error budgets keep freshness honest without a meeting per miss.
- Incident post-mortems fix the class, not just the row.
Common mistakes
- No owner — a red light with no 'whose' to escalate.
- Review gate so heavy the analysts route around it.
- Incidents ad hoc, each one a surprise instead of a choreographed case.
- No rollback story — the 'quick fix' becomes the permanent bug.
Debugging tips
- Changes dodge review → the gate's too heavy; split cosmetic vs semantic gating.
- SLAs missed repeatedly → budget the error instead of meeting-per-miss.
- Incidents recur as 'different bug' → post-mortem didn't fix the class; dig the prevention.
Interview checkpoint
Hands-on lab
- Model artifacts with owners and approvers
- Check refresh SLA and error budget standing
- Trace one incident through the path
Build a Governance Registry and SLA Check
45 min · intermediate
Quick quiz
The first thing governance needs is:
Incident post-mortems should fix the class, not just the row.