Why a Business Data Domain Model Is Key To Your Data Management Programme

After graduating from university, I started my career implementing ERP solutions. Whilst not the most glamorous of jobs, it was incredibly valuable because it gave insight and experience into how software (really) worked and how business (really) worked. This has been the grounding for my whole career.

One of my key learnings was how the ERP application was modularised: accounts payable, accounts receivable, invoicing, inventory management, general ledger, etc. The benefit of this was that it reduced the overall risk of implementations, allowed for specialisation, and provided organisations with a structured way to automate their business processes.

I've been thinking about this modular approach and where, outside of software itself, it could also be useful. It turns out that it is very useful in organisations' data management programmes, especially in improving their data governance capabilities. But how, exactly, does this work?

Why data governance programmes fail

The problem with most data governance and management programmes is that they jump straight to policies and technology implementations before answering the basic question of whose data it is.

The result of this is that multiple teams end up "owning" the same data or, more often than not, no business function owns it at all. Inevitably, it becomes IT's problem, and IT is then told by the business that "we don't trust YOUR data".

Data governance then just becomes a set of documentation with no accountability from the business.

What a data domain model actually is

How then do we solve this? Starting with a data domain model is the first step. However, it is important to define what a data domain model actually is.

• The model is a business map and not a technical document. It should describe the data landscape in terms that a business stakeholder could easily use. It is not an entity-relationship diagram.
• It is organised by how the business works and not by the source systems or applications the business uses. It should contain domains like "Client and Commercial", "Service Delivery", and "Finance". It should mirror the actual business.
• The model should answer the what, rather than the where. That can come later. It should define the business's important data entities (Client, Contract, Employee, Work Order) without caring which of the underlying applications stores them.
• It must be built using a common language. Everyone from the front line to the boardroom should use the same vocabulary.
• This model then becomes the roadmap for rolling out data governance. Once you have the map, you can agree ownership, one domain at a time.

Why a data domain model is more important than other data governance artefacts

Why is this different from other data governance artefacts? There are a few reasons:

• It creates accountability, avoiding the "everyone is responsible for data quality" statements that are often made. It ensures there is a named business leader who owns each domain and is accountable for it.
• It builds trust in the data. One of the biggest reasons that KPIs and metrics are distrusted is that nobody agrees on the definitions. Ownership of the data and business metadata fixes this.
• Data is often treated as a departmental asset instead of an enterprise one. A domain model removes the silos and enables business functions to unlock value from the data that no single team would find by itself.
• In the same way that modularised ERP reduced implementation risks, a domain model reduces the risk and cost of an organisation's data management programme. This makes addressing things like GDPR compliance, data classification, and other data management activities a lot easier.
• It provides a solid foundation for accelerating business strategy. For example, when leadership wants to launch a new proposition or enter a new market, the domain model tells them exactly which data assets they have, which are trustworthy, and who to work with to extract insights from the data.

How to bring the data domain model to life

Bringing the domain model to life is key. Once the model is defined, take the following steps:

1. Assign a Domain Owner to each domain. This needs to be a senior business leader, not someone from IT or the data team. Importantly, this person needs to be an owner not only in name. They need to understand what is expected of them and be willing to invest the time.
2. Next, build a small governance forum for each domain, working independently but aligned to the broader data governance programme.
3. Let the domains drive your data quality and improvement programme.
4. Understand where the domains intersect as this is where some of the organisation's most valuable data assets will be, and often the most contentious ones.
5. Make the domain model visible. This gives credibility to the organisation's data management initiative and will help adoption and buy-in.

What the data domain model is not

Finally, it is important to recognise what a domain model is not:

• It is not a data architecture diagram.
• It is not a source system inventory, but it is a key enabler of creating one.
• It does not need to be perfect on day one. Start with the eight to ten domains that matter most to the business and build on them from there.
• It is not an IT or data team artefact. If business stakeholders don't own it, any data governance efforts are bound to fail.

Foundations are important

Most governance programmes, data or otherwise, try to build the roof of the house before the foundations and walls. They invest in policies, tools, and training without ever establishing who owns the data.

Defining and agreeing a domain model is the single most pragmatic first step that an organisation can take. Once business leaders see their name on a domain model, and are aware of their responsibilities, the chances of your data governance programme succeeding are far greater.