Master Data Management

Master data management keeps shared records about core business entities, such as customers, products, suppliers, and locations, consistent across systems. It combines governance, data quality, matching, and distribution so teams can use trusted entity data.

itEnterprise architecture and integration

Don't Panic — Master Data Management

Master data management is the discipline of making shared descriptions of customers, products, suppliers, locations, and other reused entities agree across systems. This sounds like asking several filing cabinets to stop disagreeing about the spelling of a supplier. It is that, except the filing cabinets can send payments, ship goods, and produce reports.

The trouble begins when one supplier appears in purchasing, finance, logistics, and analytics with different identifiers and conflicting details. Each local record can be perfectly useful to its own application. None can settle the enterprise identity question alone. MDM keeps the original claims, works out which ones describe the same entity, and publishes a trusted view for the consumers allowed to use it.

The memorable machinery has three parts. Entity resolution decides which source records refer to one real-world subject. Survivorship chooses a value for each attribute according to approved policy. Provenance records where the value came from, which rule chose it, and who made an exception. A golden record is therefore not a magical record that has won a pageant. It is calculated evidence with a change history.

The surprising part is that matching is a risk decision, not a contest to merge the most rows. A false merge joins two different entities. A missed match leaves one entity split. Those errors have different business costs, so uncertain cases belong with data stewards and a safe split path, not behind an impressive-looking score.

MDM also does not repair a poor source process by glaring at it from a central hub. Source owners still fix defects where records are created. Data owners define the domain and policy. Stewards keep definitions, rules, and corrections usable. Technical teams run integration and distribution. The system works when these responsibilities connect; a database sitting alone is mostly an ambitious cupboard.

Read the intro when you need the full flow and architecture. Use the slides for the relationships among source records, best records, and the three architecture choices. Keep the cheatsheet nearby while deciding on blocking, thresholds, survivorship, provenance, and operating measures. Then try the practice session and exercise to turn a few fictional supplier rows into a mastered domain with evidence you can inspect.

Don't Panic — Master Data Management

Relevant careers