What you will learn
- How governed datasets differ from raw warehouse access
- Why certified metrics are the core of self-service trust
- The build order from datasets to metrics to user tooling
- How to stop self-service from becoming metric chaos
What this project is
Business users want answers now, and analysts cannot be the bottleneck for every question. Self-service BI engineering gives users governed datasets and certified metrics they can explore themselves, with the guardrails that keep their answers consistent with everyone else's.
The usual failure is the opposite: users get raw warehouse access, build their own definitions, and produce reports that disagree with finance. Freedom without governance is not self-service, it is decentralised confusion. The engineering work is therefore governance first, exploration second.
Core features
- Certified datasets with owners, descriptions, and freshness status, clearly marked against uncertified tables.
- A metric layer with one definition per metric, referenced by every exploration tool.
- Exploration tooling for filtering, grouping, and visualising certified datasets without SQL.
- Row-level permissions so users see only the data their role allows.
- Usage tracking showing which datasets and metrics teams actually use, and which rot.
- Change notices when a certified dataset or metric definition changes.
How it is built
- Certified datasets first. A small set of governed tables covering the questions users ask most.
- Metric layer second, defining the handful of metrics that cause the most disagreement.
- Exploration tooling third, once governed data exists worth exploring.
- Permissions and usage fourth, as adoption grows across teams.
- Feedback loops last. Requests for new datasets and metrics, prioritised by actual usage.
Technology considerations
The metric layer is the key component: a single definition service that every tool queries, so definitions cannot drift between tools. Datasets should be published as versioned views over warehouse models, not copies, so fixes propagate. Permissions need row-level enforcement at query time, not in the interface alone, or exports bypass them. Costs depend on user counts and warehouse usage; confirm with a quote.
- A metric definition service queried by all exploration tools.
- Versioned, certified dataset views over warehouse models.
- Row-level permissions enforced at query time.
- Usage tracking and change notices for governed assets.
Challenges to plan for
- Metric disagreement. One definition per metric, enforced by tooling, is the only durable fix.
- Dataset sprawl. Uncertified tables multiply, so certification status must be visible everywhere.
- Permission gaps. Interface-only controls leak through exports, so enforcement belongs at query time.
- Adoption resistance. Users return to spreadsheets if governed data is slow or hard to find, so search and speed matter.
A worked example
A regional sales director used to wait two weeks for an analyst to answer which products were growing in her region, by which time the quarter's decisions were made. With a self-service platform, she opens a certified dataset for regional sales, filters by her region and quarter, and groups by product, using the same certified revenue metric finance uses. The dataset is marked certified with its owner and freshness status visible, so she trusts the numbers she presents to her team.
When she tries to combine the sales data with a marketing spreadsheet she uploaded herself, the platform marks that combination uncertified, warning her that its definitions are not governed. She uses it for exploration but does not present it as official, and she requests a certified marketing dataset through the platform's feedback loop. Three months later that dataset ships, because usage tracking showed dozens of sales managers asking for the same thing. Self-service did not eliminate analysts; it moved them from answering routine questions to building the governed datasets everyone needed.
Who it is for, and its limits
This fits companies where business teams wait on analysts for routine questions, and where report disagreement has already caused arguments.
It does not fit a tiny team where analysts sit beside users and definitions are shared informally. It also does not replace analysts; it frees them for harder questions.
Frequently asked questions
What is a certified dataset?
A dataset with a named owner, documented definitions, freshness checks, and a promise that it is safe for business reporting.
How does self-service avoid metric chaos?
By defining each metric once in a metric layer that all tools reference, rather than letting each report define it.
Do users still need analysts?
For routine questions, less. For complex analysis, modelling, and new metrics, analysts remain essential.
How are permissions enforced?
At query time with row-level rules, so exports and API access respect the same limits as the interface.
What should ship first?
The datasets and metrics behind the most-asked questions, not a full catalogue. Adoption follows usefulness.
Can users combine certified data with their own spreadsheets?
Yes for exploration, but the result should be marked uncertified, since its definitions are not governed. Presenting it as official would recreate the metric chaos self-service exists to prevent.