In the comments on the recent blog post about multidomain MDM (Master Data Management) it was discussed in what degree multidomain MDM is much more than CDI (Customer Data Integration) and PIM (Product Information Management).
While customer (or rather party) and product are important master entity types, there are of course a lot of other master entity types. The location domain is often mentioned as the third domain in MDM, and then there are some entity types most relevant for specific industries like an insurance policy or a vehicle in public transit, and in public transit we also have the calendar as an important master entity type.
One of the entity types that doesn’t belong to party and in many ways is a different thing than a product is real estate (or real property or just property if you like).
For a realtor a real estate looks like a product of course. And it’s all about location, location, location.
Right now I’m working with the instant Data Quality framework. Here we are embracing the party domain by having access to external reference sources about individuals and companies, we are embracing the location domain by having access to external reference sources about addresses and then we are also embracing the real estate domain by having access to external reference sources about properties.
Real properties have addresses in many cases and are therefore close to the location domain. For some business processes it is a product with a product key like mentioned for realtors. For some business processes it is a security often identified by other keys than the postal address. It is related to different party roles like an occupier (or several) and an owner (or several) that may or may not be the same party (or parties).
What about you. Do you feel at home with the real estate entity type?
Liliendahl on Data Quality 
in some ways you might consider location to be more reference data than master data – an address of a building, office, house, flat etc rarely (if at all changes) – what does change is the related party data – current owner, mortgage holder, tenant etc.
That’s true Dave. This is in fact a concept within the MDM Edition of the instant Data Quality service.
Interesting… Wouldn’t you consider real estate as an “Asset” attached to a “location” that may be transferred (re-sold) to another “party”, and not a product? I tend to understand product as something which can en instanciated multiple times, whereas real estate is a mono-instance product.
Thanks for adding in FX.
Indeed, the real estates owned by you will be an asset and may be handled as such in a MDM context.
If looked at as a product, for example by a realtor, it will be mono-instance which isn’t the usual set up for a PIM solution.
It’s great info, Real Estate Domain, Key Element is Location (Address/Postal Adress) and Required GeLocation (latitude and longitude) for some properties on Highways or Outskirts of City, Product also key consideration, House/Apartments (Product) – Apartments consistent of No of Flats – Sub Products so on..
Apart from…
For Utilities and Telecom Companies required – Location, Location,
Infact required Country Level Master Location (Address) Data Management with GIS, some Govt Body has to Own and Share to Data Services – It’s going to reference to all services and other companies
Regards
Upendar
Thanks for joining Upendar.
If we look at data elements beyond postal address and geocode an attribute as the building type is usable for many reasons.
For example in data matching if you match two names on the same address the probability of that being the same real world individual is much higher if it is a single family house opposite to if it is a high rise building, a campus or a nursing home.
Hello Henrik – A provocative topic as always.
If I hear the comments correctly, the same Physical Asset, say a house, can be both Asset and Product at the same time. Would it not make sense, then, to declare the house itself a Physical Thing, give it a unique identity inside that ‘class’ and allow it to intersect with Coordinate Class entities (Street Address, GeoCodes) etc.? On a related note, while it is true that addresses do not change much, but as Google Maps has discovered when street names change whole neighbourhoods ‘disappear’. Not possible in the ‘real’ world.
Hi Henrik
In Multi-Dimensional MDM there are four Master Entities: Party, Product, Location and Asset.
A house (or other building) would be considered an Asset at a Location owned by a Party.
The Location can be referred to by Postal (or Street) Address, Geocodes, etc, whichever is the most appropriate for individual or enterprise involved, be they a utility company, resident, owner or postman.
For Realtors the house is still an Asset at a Location. What they are selling (their Product) is not the house but the services to find, view and initiate transfer of ownership of the house.
Good discussion.
Regards
John
Is a service a Product then?
Thanks Johns for joining the discussion.
I have noticed that Gartner (the analyst firm) describes the multidomain MDM landscape this way when evaluating vendor’s merits:
– Who: Customer, Supplier, Human Capital
– Where: Location
– What: Product/service, Asset, Financial
Hi Henrik
To me Gartner’s thinking is quite muddled when it comes to MDM.
The term ‘Multidomain MDM’ is totally confusing, as Domain Entities are totally different from Master Entities.
‘Who’ is simply Party. Customer, Supplier, Employee, etc. are Roles played by Party.
The term ‘Human Capital’ is wrong on so many levels. Firstly, because it implies that humans are a Capital Asset that can be exploited in order to create wealth. I am not sure how many would buy into that in the 21st Century. The term is also wrong as creates a logical contradiction putting these ‘Human Assets’ both in the Who and the What classifications!!
The Who, Where, What classification is a trite cliche that finally falls over when it comes to the What, because Assets and Products could both be termed ‘what’ but are very, very different things when it comes both to Master Entity Management and to enterprise operations.
Regards
John
Note: Multi-Dimensional MDM (or MEM) from the Integrated Modelling Method is quite different to ‘Multidomain MDM’. It is a technique shows how all of the dimensions of an enterprise can be analysed to identify the true Master Entities.
even among what seem to be straightforward – product for instance… both a sock and a A380 are products – the requirements in terms of attributes, business rules, hierarchy mgt. etc are as different as night and day (or chalk and cheese if preferred)
Dave
I totally agree that products can span a whole range of items. However, no matter what their size and complexity, they still belong to the Master Entity of Product and need to be capable of being modelled and managed as such. One may be be a simple product, the other a complex product, with many sub-assemblies and components. A good Logical Data Model will enable the enterprise to handle them all.
The attributes required to effectively manage Master Entities are dictated, not by data, but by the Business Functions (core activities) of the enterprise. If an attribute is not used by at least one Business Function then it is not required.
The same is true of Business Rules. These too belong to the Business Functions, because it is only when you are doing something that you need to apply these rule.
Good data modelling will show that night and day have very little that separates them. Also, the data structures to support the stocking and sale of chalk and cheese would be virtually identical.
John
“A trite cliche that falls over…” nice! Not just a cliche but a trite one to boot. Too bad it’s not true.
Actually, in your understanding of MDM it may be. In the model I employ (very successfully) there are 19 primitive class built from the six interogatives. Henrik and I have had several conversations along those lines..all very productive. A Service, for example, may look like it should be a ‘What’ but that’s only because MDM tries to limit ‘Master Data’ to a fixed number of Entities. In my world a Service string has to have a verb in it like the ones you used for a realtor: Find, View, Show, Transfer.
John
I was not, as far as I was aware, criticising anything you posted. I was commenting on the shortcomings of trying to shoehorn everything about Master Entity Management (MEM as opposed to MDM) into Who, Where and What. If I were going to look at an enterprise using interogatives I would use What, Who, When, How and, probably most importantly, Why. I would love to know your sixth interrogative!
I do not think that the number of Master Entities should be limited for any enterprise. The number is given by the answer to the question, “What are those things, which when linked through commercial transactions, create value or generate revenue for our enterprise?” For the majority of enterprises these would be simply Party and Product (including Service). For other enterprises this could also include Location and Asset.
Sadly, many MDM practitioners also tend to confuse Domain Entities and Master Entities. My advice to them is always to ask, ‘Would combining this entity type with another through a commercial transaction add value or generat revenue?’ If ‘yes’, it is a Master Entity, if ‘no’, then it is not.
Regards
John
Thanks for the clarification, I think, but re-reading your post you are correct: you didn’t criticize my post, just my approach – which of course you couldn’t have known about. On behalf of the ‘Who-What-Where’ folks, I accept your explanation.
I agree that ‘showhorning’ anything is a bad idea. On the other hand, without constraints there can be no progress. ironicaly, what I was trying, clumsily, to express was the idea that limiting MDM or MEM to four or five classes is too restrictive. I like your question about generating revenue, but given that any application in an enterprise uses a stand-alone class/method/state model for managing entities, would it not be wise to expand our MDM classes to include Function, State and Action? The argument is related to the revenue question on the other side of the ledger: If your application is causing waste in an organization it needs to hook into an MDM environment for alignment.
The other thing I’d like to throw into the discussion is the idea that perhaps the abstraction that separates ‘Reference Data’ from ‘Master Data’ needs to be declared as just that: an arbitrary – if convenient – device. One model’s attribute is another model’s relation.
@John O’G
One of the major problems with the current approach to MDM/MEM is that enterprises are trying to do it at application level. This will never succeed. What is needed in all enterprises is a core Business Architecture with the Function Model at the core. From the Function Model we get all Transactional, Master and Domain Data Entities.
Function cannot lie within an MDM class because it actually defines all MDM (and all other) classes. I show why this is at Busienss Modelling Architecture
Regards
John
I absolutely agree with your first statement. I would add, however, that neither can MDM start at the database layer. It must start with a clear understanding that how we classify terms, names, values and even phrases is critical to building an enterprise MDM that serves, as you say, all masters, This is, I believe, consistent with your model’s contention that MDM start in a different place.
There are six super-classes of enterprise information and all of the ‘language’ of a business can be grouped into these at an elemental level. Six is far too coarse to be precise, so I have further broken those down into nineteen. As an example. the words ‘Customer’, ‘Supplier’ and ‘Manufacturer’ are all members of the ROLE class. ROLE, USE, and DISCIPLINE are all classes under the FUNCTION super-class. The words ‘Accept’, ‘Reject’, ‘Pay’ and ‘Promote’ are all members of the TASK class, which with ACTIVITY, EVENT and PROCESS is a member of the ACTION class. ‘Payment’ is a member of the CONCEPT class.
In my world, combining ‘Accept’ ‘Customer’ and ‘Payment’ could represent a PROCESS name. which could then have an MDM representation.
The point of this is that the names, terms and phrases in an enterprise can be declared *before* they get to the semantically messy databases involved in MDM or any other application. I believe this approach is consistent with Henrik’s instant data quality approach.
John O’G
I do not see the classification of Data Types as arbitrary. I see the three major types as follows.
Transactional Data Entities. As the name suggests, these are those entities created each time the enterprise carries out a commercial or legal transaction with a Third Party. Obvious examples would be a Sale or a Purchase. Less obvious would be employment contract, a standing contract for services, etc.
Master Data Entities are, as I have previously listed, Party, Product, Location and Asset.
Domain or Reference Entities are all of those entities which are neither of the above. They are those entities whose instances are used to categorise or classify Transactional and Master Data Entities. There are instances can also be used to limit or control the value of the attributes of Transactional and Master Data Entities, for example, a list of valid countries, etc.
I have found that using these three definitions tends to remove all of the confusion that tends to surround this whole subject.
Regards
John
All classifications – especially ones employing the ‘type’ approach – are arbitrary. Take any two developers and ask them to model (Conceptual, Logical and Physical) a problem in the same domain and their decisions and hence their desing, build, test and deploy strategies will almost without exception be different.
It does not matter which digital landscape we look at, the semantics of databases, objects, taxonomies and models all conspire to compromise human communication. What is needed is a countervailing approach to the technical one that balances the mental models of mechanics with the practical (albeit less precise) mental models of the drivers.
Thanks guys for a good discussion. Always a pleasure to have quality comments on a blog post. Please carry on ….