I hear this one from clients every now and then: even the smallest table is a data product here, you can click on it, subscribe, and use it. I know the other end too, a whole schema of physical tables provided as a data product without any further description. Both go by the same name, which shows how differently the term gets used.
In the hub article for this series, I already asked the question. Take a star schema for accounting from my Dimensional Modeling Fundamentals Class, with offsetting entries, a calculation model behind it, and cost allocation across several stages, around 15 fact and dimension tables in total. Is that one data product, fifteen, or none at all?
The answer is in there too: one. The reasoning goes further than the answer, though, because it also shows what belongs to the product besides the 15 tables.
One, fifteen, or none
The same 15 tables, provided three different ways.
Fifteen data products would mean every table can be subscribed to on its own, and anyone in accounting who needs an analysis puts the calculation logic together themselves. When I tell the business to go find their stuff somewhere in the data solution, the answer is pretty reliable: no thanks. OK, there are tech-savvy business teams who are happy to do that. The question is just why. But that's another story. As a user of a star schema, I don't want to first go looking for the matching master data and join it myself.
None would be the right answer if the 15 tables just sit in a database, with no contract and nobody accountable for them. That's the picture from the hub, fifteen times over: a physical table without a description is just a table for now.
That leaves one. If you use a data product, you want a subscription to the product, not to its individual parts. For the accounting star schema, that means all 15 tables are provided together, as one unit that is only really useful as a unit.
Cut from the consumer's side
The boundary of the product follows what its consumers need.
In data mesh, a product like this is called consumer-aligned, meaning it's built around its consumers. It serves a specific group: people, and maybe agents too, who work in the accounting domain. For that group, the star schema is self-contained.
From a dimensional modeling point of view, that's the natural choice anyway. The whole reason to build a star schema is to make the data easy to consume. Split it into fifteen separately subscribable parts and you take some of that away again. Then there's maintenance: what belongs together gets versioned together. That's also how Roelant Vos and I approach it in Data Engine Thinking. So a data product ends where a group's needs end. Where a table ends says little about it. Where exactly that line runs when things are less clear-cut than in accounting is the topic of part 2.
About this series: This is part 1 of 3 in the series "Data Products: From Model to Value". The overview is in the hub article. Part 2 (November 18) looks at where the data comes from and how to cut and provide a data product. Part 3 (December 9) explores automation through information models.
Model the accounting star schema yourself
This exact star schema, with its cost allocation across several stages, is what I teach in the Dimensional Modeling Fundamentals Class. The DMFC is now available as eLearning, and the next open class runs from May 31 to June 11, 2027.
What belongs to it besides the interface
The consumer sees the contract. The owner is responsible for the whole box.
A data product is a kind of box, and how much of it you see depends on who's looking.
The consumer sees the interface, meaning the 15 tables. What matters to them is the data contract on top, written for example in the open standard ODCS. It says what they can rely on: the schema stays stable, and nothing gets deleted or renamed without warning. It also spells out the terms of use, for example when personal data is involved.
The owner sees more. Their box includes the incoming interfaces from upstream systems, or the other data products it uses, and the modules (data logistics processes) that fill the 15 tables. In accounting, that's mostly the calculation logic, all the cost allocation across several stages that populates the facts. To me, it's just as much part of the product as the tables that come out at the end, because that's where the numbers in the facts are actually created. So the interface and the modules belong together.
And someone has to be accountable for both. One team owns the interface, the quality of the star schema, and the modules behind it. Without that team, the box has no owner, and what's left is a schema in a database again.
At the drive-thru from the hub, that's the kitchen. Customers don't see it and mostly don't want to, but someone is responsible for it. And once somebody does ask for the details, there has to be an answer.
What's still open is where the data flowing into the box comes from. What if the customer or employee dimension already exists because someone else built it as a data product, and I just reuse it? That's what part 2 on November 18 is about, along with the question of where one data product ends and the next one begins. There's more on this in episode #005 of [antifragile data] (in German), where I talk data products with Simon Harrer. It goes live on November 24.
So long,
Dirk
Sources
The accounting star schema is the teaching example from the Dimensional Modeling Fundamentals Class.