Parts of this article build on the conversation with Bjarte Tolleshaug, Chief Consultant and Discipline Lead Cloud & Data at Experis Bergen, in episode 20 of the Norwegian podcast Datautforskerne (in Norwegian).
In short: Start data governance with one domain where the boundaries are clear, the owner is willing and the problem is real. Build one or two critical data products there, and make the templates as you go. The owner needs a mandate, a purpose people understand and time for the job. Write the neighbouring domains down as hypotheses, and buy tools only when the need grows.
A large Norwegian manufacturing company we at Glitni worked with this year runs forecasting models in daily operations. Advanced analytics underpins decisions with large financial consequences. Even so, none of the most important data areas had formal data ownership, quality agreements or data contracts when we started.
The problem was not capability. It was the governance layer underneath: the layer that makes the use of data safe, traceable and independent of individual people.
This is often how it starts. Someone draws up a framework for the whole organisation: policies, principles, a council, a committee. Six months later the framework is hanging on the wall, and the data is managed the way it always was.
Those who make progress start smaller. They choose one domain, appoint one owner, build one or two concrete data products, and let the rest follow. This article is the practical recipe: how to get started with data governance that works, without waiting for the big plan.
Why domains and owners must come first
Data governance most often fails because it stays abstract. A framework with nowhere to land is just words.
Domains give governance somewhere to land. A domain is a bounded area where data is used and managed for a shared purpose. A data owner is a leader with real authority in that business area. It should not be an IT role.
The best data owner is the person with the most to lose if the data is wrong, and the most to gain if it is good.
Domains are defined by use, not by the organisation chart. Two departments can share data, and the same dataset can be used in many places. But ownership must be unambiguous. Someone has to own the whole, even if many people use the parts.
This is not a Norwegian invention. Domain-driven design has talked about bounded contexts for more than twenty years: the boundaries around an area are drawn from what it means to the business, not from who sits where. Data mesh builds on this and makes the domain the unit of data ownership. We do the same. We just start by asking where the day-to-day decisions are made.
When you can’t define all the domains
In theory you map the whole organisation, divide it into clean domains and appoint an owner for each. In practice it rarely works out like that in a complex organisation. The boundaries are blurred, ownership overlaps, and if you wait for the complete model, you wait forever.
So you do the opposite. You choose one or two domains and start there.
Three criteria decide which ones:
- Clear boundaries. The domain must be possible to delimit without endless discussion about where it ends.
- A motivated owner. There must be a leader who has the most to lose from poor data here, and who wants to own the problem. Without a willing owner, the rest is theory.
- A real problem. Ownership must solve something that hurts now. An area where poor data quality is blocking results almost owns itself, because the owner sees the value straight away.
Three questions help you find it. Which figures keep coming up in management meetings? How many hours go into fixing the same errors again and again? And if one data source disappeared for a week, what would grind to a halt? The domain the answers point to is usually where you should begin.
Choose the domain where the three criteria meet. That is where you build momentum, and momentum carries the work on to the next domain.
Neighbouring domains are hypotheses
The moment you start with one domain, you run into its edges. The domain receives data from somewhere else. It passes data on. It shares definitions with its neighbour. You cannot pretend these links don’t exist, but you shouldn’t try to own them yet either.
Write them down as hypotheses instead.
“We think this dataset is owned by domain X.” “We think this metric comes from Y.” “We think these two departments mean the same thing by the term customer, but we haven’t verified it.”
An example from the engagement, anonymised: the same metric existed in several different source series, without anyone making sure the right series was used. An error in one source series propagated all the way into decisions further down the value chain. Findings like this are not flaws in the method. They are the map of where domains number two and three should go.
The hypotheses do two things. They stop you pretending the world is simpler than it is. And they give you a prioritised list of where to expand next, based on dependencies rather than guesswork.
Not all data is alike
Ask three departments what a customer is, and you get three answers. Sales counts one customer per contact person they talk to. Finance counts per organisation number that is invoiced. Support counts per case. All of them are right within their own domain. The problem arises the day the figures have to meet in one report, and nobody can agree which one is right.
The reason is that data plays different roles, and the roles have different governance needs. DAMA-DMBOK builds on Malcolm Chisholm’s taxonomy to tell the types apart. Simplified to the three that matter when you govern data:
Core data, meaning master and reference data. The core entities and codes everyone shares: customer, product, supplier, employee, location, and code sets such as country, currency and chart of accounts. The two are related but not the same: master data is the entities that change over time and must be versioned, such as a customer moving or a product being discontinued, while reference data is the stable code sets. DAMA is unequivocal: both “belong to the organization” and must be shareable across it. This is the data that is not naturally owned by a single domain.
Transactional data. The events and records from operations: orders, measurements, transactions. They are naturally owned by the domain that produces them.
Analytical and derived data. Aggregates, metrics, forecasts, reports. They are owned by the domain that creates them, but inherit their trust from the data they build on. If the source is unreliable, so is the forecast.
This determines how easily “one domain, one owner” can be put into practice. Transactional and derived data fit the model without further ado. Core data does not. If you let each domain define customer for itself, you end up with the same silos you were trying to avoid, just with clearer ownership inside each silo. DAMA puts it precisely about reference data: the key is “organizational willingness to relinquish local control of shared data.”
In practice, core data gets an appointed steward across the domains, while the domains that use it have the right to use it, not the power to define it. Sales can use the customer concept, but not invent its own. This is as much politics as it is craft. Someone has to give up local control, and that doesn’t happen without an owner with the mandate to decide.
The consequence for the order of work: start small on domains and data products, but the few shared rules for core data must come in parallel with the first domain, not afterwards. A shared definition of the most central concepts, and clarity on who stewards them. Start small on execution, not on principles.
A sign that you have a core data problem: the same term gives different figures in different reports, and you spend the monthly meeting arguing about which figure is right, instead of what the figure means.
From ownership to data product: start with one or two
Ownership only becomes real when it attaches to something concrete. That concrete thing is the data product.
A data product is not a table or a report. It is a dataset managed as a product: it has an owner, a clear purpose, known consumers, a contract for what is delivered, and a quality it stands behind. The difference between a dataset and a data product is governance.
Don’t try to turn everything into data products at once. Choose the one or two most critical in the domain you started with. Critical means two things: many depend on it, and it costs a lot when it is wrong. That is where governance pays off first.
Think MVDP, a minimum viable data product. The smallest product that is governed:
- Owner and purpose. Who owns it, and which need does it meet?
- Data contract. What is delivered, in which format, how often, with what quality?
- Documentation. What do the fields mean, where do they come from, how should they be interpreted?
Once the first data product is in place, the owner has something tangible to govern, and the rest of the organisation has an example to point to. It is easier to explain what data governance is with one finished data product than with ten pages of policy.
Templates beat one-off deliveries
The first data product is not the goal. The template is.
While you build the first one or two data products, you also build the templates that make the next one faster: a data contract template, a data product canvas, a simple roles and responsibilities template. The first time takes a while, because you are working out what the template should contain. The second time you fill it in. By the tenth time it is a habit.
This is the difference between a delivery and a capability. A one-off delivery gives you one good data product. A set of templates gives you a way of making them. It is the capability that scales, not the individual product.
A good data contract template forces the right questions: Who is the producer and who is the consumer? Which fields, and what do they mean? How often is the data updated, and what is the freshness requirement? Which quality dimensions apply, and what is the threshold? What happens with a breaking change, and how are consumers notified? How is the contract versioned?
This is what a contract looks like in practice: the order table is updated every night by six o’clock, with at most 0.1 per cent missing rows. If the promise is broken, consumers are notified before they build further on stale data. Data contracts have developed a vocabulary of their own in recent years, among other things through Andrew Jones’ work and the open standard ODCS, the Open Data Contract Standard.
One piece of advice: let the person who will steward the data fill in the template the first time, not a central function. The template should hold the domain’s knowledge, not an architect’s assumptions.
Simple tooling first, expand as the need grows
The most expensive mistake in early data governance is buying tools before you have anything to govern.
Start simple. The domain overview can live in a spreadsheet. Data contracts and term definitions can sit as documents or in a wiki, versioned in the same repository as the code, and enforced with simple tests in the data pipeline, such as dbt tests, long before you need dedicated contract tools. The catalogue of the first data products can be a simple list. The point at the start is not the tool, it is that someone owns the content.
Expand when the manual solution starts to cost more than it saves:
- A data catalogue, such as Collibra, Atlan, DataHub or OpenMetadata, when the number of data products and users makes a manual overview untenable, and people spend time searching for what exists and what it means.
- Observability and automated quality monitoring when the number of contracts makes manual follow-up of freshness and quality too heavy, and you discover breaches too late.
- Lineage when the data flow is complex enough that nobody has the whole picture in their head any more, and an error in one place propagates without anyone seeing where.
The tool should follow maturity, not create it. A data catalogue solves nothing if nobody owns the data that is supposed to be in it. We have seen catalogues costing millions sitting half-filled because ownership never came first.
How to make ownership operational
Ownership on paper changes nothing. A data owner who is named in a document but does nothing differently is worth as little as no ownership at all. The job is to make ownership operational.
Bjarte Tolleshaug sets out three requirements that must be in place at the same time before ownership becomes more than words. The owner must have a real mandate, meaning the authority to decide and to clean up when something goes wrong. Without the mandate, everything you ask for stays as polite requests, and polite requests lose out to everything else people have on their plate. The purpose must sit with the people who will do the work. If they don’t understand why the data has to be right, they have no reason to prioritise the work. And the capacity must exist. Data owner and data steward are in practice side roles of five to fifteen per cent on top of a full-time job, and what is urgent wins over what is important. If one of the three requirements is missing, the work stops, no matter how well the framework is written.
Five moves make it happen:
Separate the roles. The data owner decides: how data is interpreted, who has access, what is good enough. The data steward handles the day-to-day: following up quality, maintaining definitions and contracts. The technical responsibility for storage and access in the platform sits with architecture and IT. The most common mistake is treating data owner and data steward as synonyms. Then nothing happens, because everyone waits for someone else to decide. And whoever holds the role, the responsibility must be documented and transferable. If the knowledge only sits in one person’s head, you don’t have ownership. You have a key-person risk.
Introduce data contracts. The contract makes ownership operational. It makes it possible to handle deviations without them turning into a political discussion, because what was agreed is there in black and white.
Build a coordination model, not a new organisation. You don’t need a separate governance department. You need to know where data is dealt with in the meetings you already have, and who has which responsibility. A RACI model laid over existing forums is enough for most. DAMA-DMBOK calls this a network model: a series of known connections between people and roles.
Follow up over time. Data quality is not a number you measure once. It is a promise between producer and consumer that has to be kept. The owner must see the quality of their data regularly, not just when something has gone wrong. Nor is data governance a project. The work has neither a beginning nor an end, and once an organisation formalises governance, it is committed for good. That is why the roles must sit with the organisation’s own people from day one. A consultant can set up the model and run the first rounds, but owes the client a plan for what happens the day the engagement ends.
Treat communication as the main part of the job. Bjarte’s estimate is that fifty to seventy per cent of data governance is communication. You talk to people with very different starting points, and the same message has to be said in several ways before it sticks. If you plan governance as a technical task with a bit of information on the side, you have turned the relationship upside down.
Maturity: the five levels
It helps to know which level each domain is at. We use a model with five levels:
| Level | What it means |
|---|---|
| Basic needs | The data exists and is accessible. |
| Stability | The flow is operationally reliable, with version control and predictable delivery. |
| Trust | Ownership, quality and contracts are in place. The data can be trusted. |
| Mastery | Users serve themselves, because definitions and access have been sorted out. |
| AI and predictive models | The data is the foundation for advanced analytics in production. |
The most common pattern we see is organisations operating at level five while the foundation at level three is missing. Advanced analytics runs in daily operations, but ownership, quality and traceability are not established. The gap is not the ability to analyse. It is trust. Without logging, versioning and traceability, nobody can explain why a forecast turned out the way it did, and reproducibility is not an academic requirement when the model drives real decisions.
Once the first domain has a template and a couple of data products at level three, you scale through a federated model: a central function sets shared standards for quality, security and access, while each domain has its own owners who apply the standards locally. Central governance of the principles, local accountability for the data.
When the method falls short
Starting with one domain has a weakness, and it is worth saying out loud.
Some data is cross-cutting by nature. Master data and reference data, such as customer, product or organisation, are used everywhere and are not naturally owned by a single domain. If you let each domain define customer for itself, you end up with the same silos you were trying to avoid, just with clearer ownership inside each silo.
The consequence is not that the method is wrong. The consequence is that the few shared rules must come in parallel with the first domain, not afterwards. You start small on domains, but you don’t postpone a shared data contract template, a shared vocabulary for the most central concepts, and clarity on who owns the master data. Start small on execution, not on principles.
It is also worth saying that not everyone needs full decentralisation. For a smaller organisation, a lighter model can hold for a long time. The method here is about order and momentum, not about copying an architecture from a large technology company.
Good practice points the same way
It is easy to claim that “start small” is right. The established frameworks point the same way, each from its own vantage point.
DAMA-DMBOK, the industry’s standard reference for data management, is clear: “Rarely is DG deployed enterprise-wide as a first effort.” Most rollouts are incremental. The book highlights the principle “evolution not revolution”, and describes the network model with RACI as the natural first step before formalising further. The federated model is described as a centralised strategy with decentralised execution, and for large organisations often the only one that works.
Data mesh, formulated by Zhamak Dehghani, makes domain-oriented and decentralised data ownership a core principle, with the domain’s bounded context as the boundary for ownership, and the data product as the deliverable. Our experience is that a step-by-step introduction beats a big-bang reorganisation. Those who announce that “now we’re doing data mesh” and restructure everything at once often end up with neither the benefits of decentralisation nor the clarity of central control. That is why we recommend starting with one or two domains that have clear boundaries, competent people and a real problem ownership can solve.
It is the same recipe we use. Not because it is in a book, but because it works.
A rule of thumb
If you can’t name one person who has the most to lose if a particular dataset is wrong, you don’t have a domain yet. You have a hypothesis. And it is perfectly fine to start there.
How to get started:
- Choose the one domain where the boundaries are clear, the owner is willing and the problem is real.
- Build one or two critical data products, and make the template as you go.
- Keep tooling simple until the need grows, and establish the few shared rules from the start.
- Write the neighbours down as hypotheses. Then expand.
If you get the job and a hundred days, the three requirements are the plan, but purpose comes first. Find the one problem the organisation already knows it has, and make sure you have chosen correctly before you move on. Use the next period on the mandate, that is, on placing formal ownership with someone who has real authority. Then solve capacity by finding people who can set aside time. Don’t buy tools, and don’t write policies and a big framework. The basic principles for the roles are enough for everyone to know who is who, and then you have come a long way in a hundred days.
What would be the first domain in your organisation?
Frequently asked questions
What is data governance? Data governance is the framework for how an organisation manages its data: who owns it, which rules apply to quality, access and use, and who is responsible when something is wrong. Data ownership is the operational core that makes the framework real.
What is a data owner? A data owner is a leader with real authority in the business area the data belongs to. The owner decides how the data is interpreted, who has access, and what counts as good enough quality. It should not be an IT role.
What is the difference between a dataset and a data product? Governance. A dataset is just data. A data product has an owner, a clear purpose, a data contract and a quality it stands behind.
What is core data? Core data is master and reference data: the core entities and codes the whole organisation shares, such as customer, product and supplier, and code sets for country and currency. It is not naturally owned by one domain and needs shared definitions across domains.
Where do you start with data governance? With one domain and one owner. Choose the area where the boundaries are clear, the owner is willing, and poor data costs money today. Build one or two critical data products there, make the template as you go, and expand from there.
Do we need data mesh to get started? No. The principles from data mesh, domain ownership and data as a product, are useful regardless of size. But full decentralisation is not a goal in itself. Smaller organisations manage for a long time with a lighter model.
Learn more
Related reading on glitni.no:
Sources and further reading:
- Datautforskerne, episode 20: Dataforvaltning med Bjarte Tolleshaug (in Norwegian), 2 November 2026
- DAMA International, Data Management Body of Knowledge (DAMA-DMBOK), 2nd edition, 2017
- Zhamak Dehghani, Data Mesh Principles and Logical Architecture, martinfowler.com, 3 December 2020
- Eric Evans, Domain-Driven Design, Addison-Wesley, 2003
- Andrew Jones, Driving Data Quality with Data Contracts, Packt, 2023
- Bitol, Open Data Contract Standard (ODCS), version 3.2.0, 8 September 2026
Listen to the full conversation with Bjarte Tolleshaug
Listen to the Norwegian podcast “Datautforskerne”, episode 20, where Bjarte Tolleshaug and Magne Bakkeli talk about why data ownership doesn’t work without mandate, purpose and capacity, and what to do in the first hundred days. The episode is available on Spotify, Apple and Acast. In episode 19 we talked about how good the data needs to be.
Magne Bakkeli is co-founder and senior advisor at Glitni. He has over 25 years of experience in data platforms, data governance and data architecture, and led the Data & Analytics team at PwC Consulting for 12 years. He has built and modernised data platforms across energy, FMCG, finance and media.