The pevious post on this blog was called A Master Data Mind Map. In there I tried to map some different examples of master data entities within some known master data domains as party, product, location, financial and calendar.
In the comments and in a following twitter conversation, the placement of the asset entity was questioned.
Prash Chan (@MDMGeek) said: “There is another type of asset I came across once, mapped to location domain, largely because the assets were identified by the place where they were installed.”
Jamie Watters (@jamietwatters) said: “Don’t disagree, but think there are other areas of asset data that makes it unique instead of using product or location. Areas such as engineering, design, construction, maintenance, commissionin make managing asset data pretty unique.”
Indeed, I am actually also on the fence here.
There are certainly often strong relations to a location for an asset. But that is also true for parties as well and some products too as told in the post Product Placement.
Assets can be many things. Gartner (the analyst firm) has the concept of the things domain encompassing products and assets.
Asset may in fact just be its own domain. Property too perhaps as the Real Estate Domain. Services could claim independence from the other products someday. Customer is today often seen as its own domain not belonging to party as examined in the post MDM for Customer Data Quadrant…
Andrew White of Gartner did address these naming issues in a blog post back in 2009 here.
Liliendahl on Data Quality 
Hello Henrik;
The “asset” challenge points to a larger question of what it is we are trying to model. A house is an asset sitting at a given set of coordinates, be they GPS and/or street address. The location, however it is expressed, is not the asset itself, just a convenient proxy and therein lies the problem. It’s similar to saying: customer is-a person. An address is just a label an asset wears (just as customer is a role an agent plays) and the two should be separate.
If we move the house does it change its identity? If a person (customer) changes hats to become a supplier the same question applies. In fact, the model I’m working with says the more articulation (soft-wired as opposed to hard-wired connections) you can build into a model, the more useful it becomes.
I’m agree with John, asset is not a top-generic-abstract entity that would encompasse a lot of various master data entity.
I pick up various definitions (wikipedia, my own dictionnary) of what is an asset, and it’s commonly accepted that master data are perhaps the most valuable assets for a company. But In my opinion Asset is definitelly not a master data entity nor a group of master data entities. It’s a particular view on Master Datas, it represent the value a master data has for that company.
We can have an asset entity in our model, but it should be limited to financial accounting and should not encompasse other entities such has product or customer.
Henrik
Prior to developing my Multi-Dimensional MEM techniques I got some great input on Assets from real experts in Asset Management that totally convinced me to include it. I am so glad that I did, as it has proven a real boon when dealing with many of my clients. Gartner are definitely way off the mark with a ‘things’ domain. Products and Assets are entirely different entities and need to be identified and managed in entirely different ways.
Assets are definitely not merely a view of Master Entities. A locomotive or a milling machine is not a view of Party, Location or Product; it is an item of significance to be managed in its own right.
To be properly managed, Assets always need to be linked to a Location but they are not a Location, which is an entity in its own right.
The suggestion that Customer is a Master Entity is its own right is pure @*$x!#!!! What will it take to overcome people’s myopia in this area and get them to finally realise that Customer is merely a Role played by Party, as are the Roles of Customer, Agent, Guarantor, etc, etc.?
Regards
John
Henrik,
Appreciate you triggering this dialogue. I am in agreement with John above that there is value, and reason, to treat assets as an individual domain. As one example, physical assets need to be maintained. The unique characteristics, objects and attributes related to maintaining of assets is what can be called “Maintenance Master Data” and is not represented properly in current MDM domains. Geo-spatial (location) data is definitely an aspect of asset master data that must be included.
Some asset intensive organizations are just starting to realize that they have asset master data challenges (wow – we really have ‘x number’ of systems that have duplicate asset data in them??), and initial thoughts are to use the ERP system for this. That doesn’t work either. It will be interesting to see the asset domain mature in the next 5 years.
Jamie
@Jamie – I think the asset domain is about to mature in a lot less time. I would map the domains a little differently than Henrik – and take a much broader view than Finance in the process – as Asset is a class that can contain many different ‘types’ of things, both fungible and unfungible. The key, as John Owens suggests, is the separation of the function of a ‘thing’ from its identity and its spatial representation. It is also important to understand that there are also ‘non-functional’ concepts that intersect the Asset class which also need to be managed independently.