What is a Data Model and Why Should Non-Engineers Care?

Most companies I talk to are drowning in data and starving for answers. They have a CRM, a product analytics tool, a finance system, maybe a data warehouse someone set up eighteen months ago. The dashboards exist. The reports get built. And yet, when the CEO asks a simple question like “how much revenue did we generate from customers who signed up through paid search last quarter?”, the answer takes two weeks, comes back different from two different people, and nobody is quite sure which number to trust.

This is not a data problem. It is a data model problem.

What a data model actually is

Think about building a house. Before a single brick is laid, an architect draws up a blueprint. That blueprint defines what rooms exist, how they connect, where the load-bearing walls go, and how the plumbing runs behind the scenes. It makes explicit decisions so that the builders don’t have to improvise as they go. Without it, you might still end up with four walls and a roof, but the kitchen will be awkward, the bathroom will be in the wrong place, and knocking through later will cost you far more than it would have up front.

A data model is the same thing, but for your data. It is a structured plan for how your business’s information is organised, named, and connected. It defines what a “customer” means in your system, what a “transaction” is, and how those two things relate to each other. It makes those decisions once, deliberately, rather than letting every analyst and every dashboard reinvent them independently.

That last part is where things go wrong. Without a shared model, every team builds their own version of the truth. The marketing team’s definition of “active user” doesn’t match the product team’s. Finance calculates churn differently from customer success. Your dashboards contradict each other not because anyone made a mistake, but because nobody ever agreed on the foundations.

What goes wrong without one

I’ve worked with companies where the data infrastructure had grown organically for a few years before anyone stopped to think about how it was all structured. The symptoms are always recognisable.

Your analysts spend most of their time cleaning and wrangling data rather than actually analysing it. A query that should take an afternoon takes a week because nobody is sure which table to trust or how the joins are supposed to work. New hires spend their first month trying to reverse-engineer what the existing tables mean. Leadership stops trusting the numbers, so they stop asking for them, and the whole investment in data tooling quietly stalls.

The worst version of this is what engineers sometimes call a data swamp: a repository where data arrived from everywhere, nothing was ever given structure, and now nobody dares touch it because they don’t know what will break. I’ve seen teams effectively park entire data platforms and start over because the cost of untangling what was there was higher than rebuilding from scratch.

This is a business decision, not a technical one

Here is something that often surprises founders and product leaders when I say it: designing a data model requires your input, not just your engineers’. The decisions that shape a data model (what counts as a sale, when a customer is considered churned, how you attribute revenue across channels) are business decisions. Your engineers can implement the model once those decisions are made. They cannot make the decisions for you.

The two dominant approaches to data modelling, which are named after the engineers who pioneered them, Ralph Kimball and Bill Inmon, reflect two different philosophies that are still very much alive in modern data work. Kimball’s approach, called dimensional modelling, organises data around the questions your business wants to answer: it is fast, intuitive, and great for teams that need dashboards and reports quickly. Inmon’s approach builds a central, highly normalised repository of business truth first, then serves data out to teams from there: it takes longer to set up but scales better as the business grows in complexity. Neither is universally right. The choice depends on where your business is and where it is going, and that is a conversation worth having before your engineers write a line of SQL.

The companies I’ve worked with that get data right are not always the ones with the biggest teams or the most sophisticated tooling. They are the ones where someone at the leadership level understood that how you organise your data is a strategic choice, and treated it like one.

Where to go from here

If any of this sounds familiar: your team is producing reports that don’t agree, your analysts are stretched thin on data wrangling, you’ve invested in data infrastructure but still feel like you’re flying blind. The problem is probably not the tools. It’s the foundations underneath them.

A good data model won’t solve everything overnight, but it will make everything else work better: faster reporting, dashboards your team actually trusts, and analysts who spend their time finding insights rather than fixing queries.