[wd_hustle id=’Social’ type=’social_sharing’/]

What does an MDM Hub and a game of golf have in common? Both have participants that are likely to be separated by several decades.

This generation gap leads to some interesting MDM situations (and some interesting golfing situations but they extend beyond the boundaries of this article). Consider this example of a legacy mainframe record for the University of Wisconsin compared to the data stored within the MDM Hub.

There are many differences between the records but only one that really represents a difference in business information. The key is to be able to separate differences that matter from those that don’t.

Case

Most legacy systems literally shout I’M OLD MAINFRAME DATA in uppercase only. Modern systems prefer the more pleasing Title Case. Case differences don’t represent a difference in business data so we treat fields like Street and City as identical values.

Name 1

The Name1 field is clearly different but means the same thing. The mainframe system holds a contracted version of the university name to squeeze this name into 30 bytes. This contraction is typical of mainframe data where each byte was valuable. If we want to compare the source record to the Hub we need first to transform the mainframe data by expanding contractions. The expanded Name1 data can be considered equivalent to the hub data but not identical.

Street and City

Street and city are identical between the two systems (ignoring case). The equivalent Name1 and the identical Street and City data is enough for us to consider these two records to be good match pair even though there is a serious defect in the complete mainframe address.

State

There is a Madison in California but there is no N Charter St in Madison California – and it’s certainly not where the University of Wisconsin is located. It is no surprise that the mainframe data has no Zip code as the address has clearly never been validated. Within the MDM Hub we apply USPS address validation to figure out which Madison is correct based on the Street and also to lookup the Zip+4 code for this address.

Comparing the Records

So, an MDM comparison of the two records yields:

• There is no difference between the business meaning of Name1. As the mainframe system is unable to hold the expanded Name1 there is no need to communicate a difference back to the mainframe.
• The mainframe has an incorrect address and requires an update to State and Zip.
• The mainframe only holds a 5 digit Zip code and therefore only receives the first 5 digits. The mainframe zip is now considered the same as the master even though the master holds an expanded form of the Zip.

When the mainframe is updated with the changes it is able to consume we end up with the following.

The MDM Hub will treat these records as equivalent representations of the same business information.

Summary

The MDM process must consider the technical restrictions of contributing systems when making comparisons between information. The MDM Hub must be able to distinguish between how data is stored and what it represents.