The entities everything else points at
A purchase request names a supplier. A stock movement names an item and a warehouse. A price list names both. A report groups by product category. A process routes by counterparty type.
None of those systems owns the supplier, the item or the warehouse. They refer to them - and what they refer to has to live somewhere that is correct, shared and stable. That somewhere is master data.
What usually happens without one
Every platform has three things that look like they could hold a catalogue, and none of them is one.
| What gets used | Why it breaks |
|---|---|
| A spreadsheet | An editing surface, not a store. Fine for two hundred rows; a hundred thousand SKUs with a lookup on every checkout is a different job |
| An analytics dataset | Built for aggregation over many rows, not for answering "what is the price of this one SKU" on a hot path |
| A dictionary inside some other subsystem | Right shape, wrong owner - it belongs to that subsystem's lifecycle, lives behind its API, and takes your catalogue down with it |
The last one is the common ending: the product catalogue lives inside whichever subsystem needed it first, and every other part of the platform fetches it over the network, unindexed, on paths that cannot afford it. It works until it is the thing everything depends on.
What is different here
The attributes are yours. What a product has - a category, a unit, a shelf life, a supplier code, three fields nobody else would have thought of - is declared by the application that needs them. Adding one is not a platform migration somebody has to write and deploy for you.
It is stored as real tables, beside your other data. Which means the catalogue can be joined to anything: a report joins products to sales, a process reads a counterparty in the same query it reads the request. Master data behind another service's HTTP API is the failure this exists to end.
Codes are immutable, and entries deactivate rather than vanish. Everything else - a balance in the ledger, a field on a task, a row in a report - refers to an entry by its code. A code that can be renamed is a way to orphan all of it quietly.
A catalogue ships with an application, and your edits survive its updates. The application declares the entity and can seed it with the values it needs to work. Seeding never overwrites a row that already exists, so what your operators corrected stays corrected - and a new value added in a later version still arrives.
Where to go next
- What you can do - what belongs here, who maintains it, and how it reaches processes, reports, pages and the ledger.
- Under the hood - how declared attributes get native speed without giving up free evolution, and the rules that keep a shared catalogue from drifting.