How to identify your company's data domains, step by step
What a data domain is
A data domain is a set of data that shares the same business meaning and has one responsible person. Common examples are customers, products, suppliers, finance or people. It helps you decide who answers for which data, and to organize the catalogue and the data quality rules.
A six-step method
- Secure leadership support and set the scope. Without a sponsor who asks each area to take part, the map stays a draft.
- List the main business processes. Selling, buying, invoicing, hiring, producing. If you already have a process map, use it.
- Identify the data entities in each process. What keeps showing up: customer, order, product, invoice, employee. Note which data is critical.
- Group the entities into candidate domains. Put together the ones that share meaning and owner. If an entity appears in several processes, decide which domain it belongs to.
- Check against the org chart. It helps you find areas and possible owners (with help from HR). But it is only a reference: two areas can report to the same director without being the same domain, and a domain can cross several areas.
- Validate with the business and assign one owner per domain. Meet each area, adjust the map and write down who the data owner of each domain is. Then start with a single domain.
Example domain matrix
This is an illustrative example; the domains and areas depend on each company.
| Domain | Main entities | Processes where it appears | Owner (area) |
|---|---|---|---|
| Customer | Customer, contact, contract | Sales, invoicing, support | Sales |
| Product | Product, price, catalogue | Production, sales, purchasing | Operations |
| Finance | Invoice, account, journal entry | Invoicing, accounting close | Finance |
| Suppliers | Supplier, purchase order | Purchasing, payments | Procurement |
| People | Employee, position, payroll | Hiring, payroll | Human resources |
Common mistakes
- Copying the org chart. Creating one domain per director, or merging different domains because they report to the same person.
- Creating too many domains. A practical rule is to have no more domains in the catalogue than processes in the process map.
- Defining domains by system. Systems change; business meaning lasts longer.
- Not assigning an owner. A domain without a name attached is not governed.
- Trying to cover everything at once. One domain done well beats ten done halfway.
Where to start
Pick the domain whose data most affects decisions or risk. In many companies that is finance, but it can be customers or products. When it works, repeat the method with the next one. To split the responsibilities within each domain, see the guide to data governance roles and owners and stewards in a multinational. To organize it afterwards, see the data catalogue guide and how to get areas to use it in change management.
This method is a practical, indicative synthesis aligned with the DAMA-DMBOK approach; it does not replace an analysis of your organization.
Quick questions
What is a data domain?
A group of data that shares a business meaning and has a clear owner, for example customer, product, finance or suppliers.
How many data domains should a company have?
There is no right number. A practical rule is to have no more domains than processes in your process map, and each domain should have an owner who can actually look after it.
Which domain should you start with?
The one that matters most to the business. Many companies start with finance because its data is widely used and has direct impact, but it depends on your case.
Who defines the domains?
Whoever leads data governance proposes the map, but each business area validates it. Domains should reflect business needs, not the structure of your systems.
What's your Data Governance maturity?
Free assessment with your priority gaps and the templates on the Data Governance path.