In the last post we looked at the use case for master data in which the consuming application expected a single unique representative record for each unique entity. This would be valuable in situations for batch accesses like SQL queries where aggregates are associated with one and only one entity record. This week, we look at a second use case that might be more common in an interactive environment where the users desire access to all the data associated with a particular entity, such as customer service or fraud investigation.
Because an MDM system applies identity resolution to link sets of records together from one or more data sets, collections of matched records can be assigned a common entity linkage identifier that indicates a grouping. In a customer service example, sales records, support call records, returns and social media comments can be linked to the unique customer.
Due to the diversity of the source data, it is unlikely that a single record will add as much value to the customer service representative’s interaction with the customer as having access to the entire set of customer touch points and transactions. This perspective might be what the vendors often characterize as the “360-degree view of the customer,” although I prefer to refer to it as a composite record.
The composite master record provides visibility into enterprise information about an entity without forcing any application of survivorship rules. One of the main benefits of the composite view is that interpretation of the data is completely left to the user. For an application such as fraud analysis, having access to data that has not been cleansed or standardized may be preferable to materializing a single record. Because details of prior interactions may show behaviors intended to hide suspicious activities using variations of names or locations, the ability to establish links among raw records can facilitate identifying fraudulent activities.
Whether your business processes rely on use case 1 (the single record) or use case 2 (the composite record), it is still difficult to convey a description of what MDM does without being able to show what it does – and devising an MDM demo is the topic of our next post!
1 Comment
Hi David,
Great point. While I have seen use case 1 ( single record) all the time, the way use case 2 is realized is by still creating single record but providing lineage information as part of MDM solution itself so the user of the application can demand access to raw (before standardization/transformation/cleansing) data coming from source. I have also seen scenarios where 'aggregate view' is created before confirming the merge so the user knows the result of the merging before hand. Have you seen use case 2 done differently?
-Prash