How I'd structure a data function as a business grows: where the data people sit, and how the tables everyone shares stay to one design. It keeps the parts of data mesh that work, and adds a shared layer built around business concepts, so the people using the data don't have to work out how the domains fit together before they get an answer.
Put data people where the data work is. Build each business concept once.
Data mesh is right that data people do their best work close to the teams that create the data. The blog post covers why, and the pitfalls it fixes. This piece is the framework: how the team changes at each stage, and the two routes to one design for the things every team shares.
Most product organisations are already split into domains, and each domain into smaller areas with their own software and their own data. Architects call these bounded contexts. Billing and payments might both sit in a finance domain, for example.
So the real question is how far into the domains data people should go, and that depends on how much data work there is. Where every context produces data people care about, each one gets a data analyst, plus an analytics engineer, data engineer or data scientist when the work needs one. They learn the detail, sit in the planning and catch problems at the source. Where the data is thin, the data people sit at domain level and cover all of it. Putting someone in every context there would leave them with too little to do.
Every product team should still have a product analyst, whatever the domain. A product analyst works on the product itself, such as how people use a feature. A data analyst works on questions that cross the business, like what a customer is worth, and needs the data function behind them.
You don't start with the at scale picture. You start with everyone central and move people out as each domain earns it, usually when its questions start queuing behind everyone else's.
The questions a business most wants answered usually cross domains, and need data rolling up or down. How many live customers have a balance? Whether a customer is live sits with one team, and their balance with billing, rolled up from bills and payments.
Data mesh has a place for these: aggregate data products, which combine several domains. Dehghani is wary of big ones that try to serve everyone, like a customer 360, and would rather each consumer build the view it needs. That leaves the hard part with whoever uses the data. To answer a question that crosses domains, they need to know which domains hold the pieces, and how to join them at the right grain. Every new question starts with that work, so it takes longer to get value from the data. In practice, it falls to the reporting teams across the business, and now the AI tools that read the data. Each does it its own way, and that can add up to hundreds of overlapping tables. The same data gets processed again and again, which costs money, and the same question gets different numbers depending on who answers it.
So the layer most analysts use should be modelled on the business. It takes a concept like a customer and brings in data from every domain, rolled up or down to that concept's level. Ralph Kimball called tables like these conformed dimensions. There's one customer table, at one row per customer, and anything known at the customer level goes on it, whichever team created it. Anything at a different level, such as each bill, goes on that concept's own table. Where history matters, it's kept at its own grain, as a daily snapshot of each customer or with an analysis date built into the table, depending on what it's for. One concept at one grain keeps each table simple to read and hard to misuse.
I'd go a step further than Kimball's star schema and make these tables wide, with the joins and roll-ups already done, so they're ready to answer analytical questions and to serve AI. They also answer questions nobody has asked yet, because the data is already in one place, in a shape the business recognises.
Modern platforms are what make this work. The star schema was designed for row-based databases, where a query read whole rows and storage was expensive, so keeping descriptions in their own tables kept the facts lean. In an open columnar format like Delta or Iceberg, a wide table costs little, because a query only reads the columns it asks for. In a distributed database, large joins are the expensive part, because they move data between machines, and a join at the wrong grain quietly double counts. Doing the joins once, when the table is built, avoids both.
That matters for AI even more, because an agent finds everything about a customer in one table, with no joins left to get wrong. Early research points the same way. In a 2026 Berkeley benchmark of data agents, the best agent answered just over half its questions correctly first time, and giving agents a semantic layer raised their accuracy significantly.
Metrics follow the same pattern. One central framework stores every metric in a standard structure, and the domain teams add their own to it. Each metric means one thing wherever it's asked for, and a different definition gets a different name.
Every domain builds to one design, and both routes end in the same place: tables built around business concepts, ready for analysts and AI to query. How they get built depends on the size and shape of the organisation.
Shared tables, built together. In a smaller organisation, or one whose architecture is mature, the domains add their own columns straight to the shared tables, to each table's rules. There's one hop from a domain's data to the table the business uses, and these shared tables are the gold layer. This is the at scale view in the diagram.
Domain gold with a platinum layer. In an enterprise, having every domain write to the same tables gets slow and risky. Instead, each domain builds its own gold tables to the shared design, and a platinum team in the platform and data domain builds a thin layer on top, which I call platinum, one step on from gold. It only joins the domains' gold tables into the shared tables, and rolls the data up or down to the level the business needs. This is the enterprise view in the diagram.
The platinum team has to keep the layer thin. Its only jobs are joining tables that already follow the design, and changing their level, such as rolling bills and payments up to a balance for each customer. The rules for those roll-ups, like what counts towards a balance, come from the domain that owns the data. Once the platinum team starts making those rules itself, it becomes another central team with a queue.
Either way, the design comes from the platform and data domain. It holds the data architecture, the data and AI platforms, and the discipline leads. It doesn't build the domains' data. It sets the standards they build to, and gives them a platform where following the standard is the easy option.
Who owns the customer table? Each team owns the columns it adds, and one owner holds the table as a whole: its grain, its rules and its quality. With a platinum layer, the domains own their gold tables, and the platinum team owns the joins.
Doesn't that bring back the central queue? Only if the data team adds every column. The domains add their own, to the table's rules and through contracts. The data team sets the design and reviews changes, and leaves the work with the domains.
Won't the tables sprawl? They will without rules. Only attributes at a table's grain go on it, columns follow one naming standard, and there's a way to retire the ones nobody uses.
Can one domain's change break a shared table? It can, which is why each domain publishes through a contract that says what the data means, when it arrives and who owns it. The analytics engineer in the team sees a change coming and checks it against the contract before it ships.
Early on, everyone in data reports into the Head of data. That's right while the team is small and sits together, because the person setting the standards can also see the work.
Once data people are spread across the domains, that stops working. An analyst ends up with two bosses: the team that sets their work, and a manager in the data function who rarely sees it. So I'd move line management to the team. The engineering manager manages everyone in it, data people included.
What stays with the data function is the craft. Each data person keeps a dotted line to their discipline lead, who sets the standard, runs hiring and owns the career framework. The discipline lead also feeds into every review and calibrates pay across the discipline. It's the reverse of the original Spotify model, where the discipline lead was the line manager. I'd rather the person managing you sees your work every day, and the person judging your craft does it for everyone in that discipline.
That also changes the Head of data's job. With engineering managers doing the line management, the head is free to lead the data strategy and the design everyone builds to.
Is your software split into domains with clear boundaries? If not, start there. Data ownership follows the software, so it can't create the boundaries for you.
Where is the data work dense? Put people in the contexts there, and at domain level everywhere else.
Does each business concept have one table? If two teams can give different answers to the same question, fix that before any ownership moves.
Can the domains write to the shared tables safely? If they can, build the tables together. If not, have each domain build its own gold tables, and add a thin platinum layer on top.
Start with contracts and one design, because they pay off at any size. Then move people out, and their line management with them, as each domain earns it.
Two measures show whether this is working. One is how long a question waits for a data person, which should fall as each domain earns its own. The other is how many metrics have more than one definition, which should fall towards none as the shared tables and the metric framework fill out. For the wider picture, the data maturity curve shows where the whole business sits.
This leans further into shared aggregates than Dehghani would. Her worry is that they grow unwieldy, and it's a fair one. But hundreds of tables built by each consumer are unwieldy too, only spread out where it's harder to see. The four questions above are how I'd keep the shared tables in check: one grain per table, and an owner for every column. The shared tables also take time to build. For a one-off question, building your own view can be quicker. The gain comes with every question after that.
This comes from scale-ups, where one product grows into many teams. In a large enterprise made of separate businesses, with little shared between them, a fuller data mesh may be the better fit, because there are fewer shared concepts to keep to one design.
One design needs someone to hold it. A good data architect makes it work, but if every change waits for their review, the queue comes back in a different place.
Moving line management only works if the engineering managers value the data work. If they don't, data people end up as spare engineers, and the discipline lead needs enough say to stop it.
And it depends on the software. If the product isn't split into domains with clear boundaries, the data can't be either, and no data structure will fix that.
This is my synthesis, from running a data function through each of these stages and from the sources below. The shared design comes from Kimball. How it gets built, by the domains on a self-serve platform, comes from data mesh.