Master Data Management (MDM) has traditionally been mostly about party master data management (including not at least customer master data management) and product master data management. Location master data management has been the third domain and then asset master data management is seen as the fourth – or forgotten – domain.
With the rise of Internet of Things (IoT), asset – seen as a thing – is seriously entering the MDM world. In buzzword language, these things are smart devices that produces big data we can use to gain much more insight about parties (in customer roles), products, locations and the things themselves.
In the old MDM world with party, product and location we had 3 types of relationships between entities in these domains. With the inclusion of asset/thing we have 3 more exiting relationship types.
The Old MDM World
1: Handling the relationship between a party at its location(s) is one of the core capabilities of a proper party MDM solution. The good old customer table is just not good enough as explained in the post A Place in Time.
2: Managing the relationship between parties and products is essential in supplier master data management and tracking the relationship between customers and products is a common use case as exemplified in the post Customer Product Matrix Management.
3: Some products are related to a location as told in the post Product Placement.
The New MDM World
4: We need to be aware of who owns, operates, maintains and have other party roles with any smart device being a part of the Internet of Things.
5: In order to make sense of the big data coming from fixed or moving smart devices we need to know the location context.
6: Further, we must include the product information of the product model for the smart devices.
Expanding to Business Ecosystems
In my eyes, it is hard to handle the 3 old relationship types separately within a given enterprise. When including things and the 3 new relationship types, expanding master data management to the business ecosystems you have with trading partners will be imperative as elaborated in the post Data Management Platforms for Business Ecosystems.
Liliendahl on Data Quality 
The use case has always been important in MDM. I think your post also points at the implications of IoT on the practice. If your IoT use case is asset maintenance, the IoT use case will call for much more precise master data. Before, someone called you if the asset was not working. Now, you may call on them because the sensor is sending information about an impending failure. Does your organization just show up because you have a contract (like you do with department X) or call first to see if they want it fixed because you do not have a contract? Is the asset at 123 main street, or at 123 main street, on the 17th floor in the southwest corridor behind ceiling panel 7? And if I am proactively arriving to prevent failure, I had better know that the product has a special configuration if I want to bring the right part.
Very good examples Gino. Thanks for adding in.
IoT and similar developments are indeed breathing new life to MDM. I like to emphasize the concept of “Installed Base” – the units of products and or services actually in use at a given time.
The nature of “Installed Base” naturally differs significantly depending on the nature of services/products. If we’re talking about the base of installed “things” in an electric network making measurements of type X or talking about installed heavy machinery in mines (that may have IoT components) or about telecom services, the details vary wildly.
But the baseline stays: one needs to have the data about the Installed Base readily available, and much of that Installed Base data is, well, by its definition “Master Data”.
And like in Henrik your picture, this “Installed Base” data is not neatly falling to any existing domain, is not fully a new domain, but is a novel combination thereof.
Greetings from Finland, Kimmo
Thanks for commenting Kimmo. Yes, an ever recurring issue with master data is about which entities are still active in real life and which are not.