Changing a Match Rule

When we are talking to companies about our MDM platform we cover a broad range of topics, from measuring ROI, to more technical questions about the way the software operates. A common technical question is “How do we change a match rule?” Our answer – “With a great deal of care and planning!”

In this article, we will talk about why the data governance considerations relating to the changing of a match rule (or any MDM rule) are far more important than the mechanics of implementing the change.

By Martin Dunn

Project

Management

Over the past few years we have seen an explosion in the number of MDM software products available. The sheer number of MDM products has created some confusing messages for the MDM sponsor/buyer/architect. The question about changing a match rule is often a gateway for us to understand the scope and complexity of the underlying MDM needs of the organization.

For the sake of simplicity, let’s divide the MDM world up into Workgroup and Enterprise solutions. Within Workgroup MDM we have companies that are trying to improve data quality within a single application or collection of files. The focus of Workgroup MDM is on improving data quality and reducing duplication within a file. Workgroup deployments view MDM products as tools to help cleanse and match data and therefore questions about creating or changing MDM rules are perfectly valid enquiries about using a tool’s GUI.

In an Enterprise MDM solution, data spans multiple applications from different parts of the business. An Enterprise MDM Hub must manage the integration of data between these disparate systems and establish a data governance process in which multiple stakeholders will participate. For enterprise MDM, data cleansing and matching rules are just steps in the process of achieving this integration and not the raison d’etre. As such, changing a rule is not something that can be taken lightly.

Consideration #1: Are you changing something that is incorrect?

 

This represents the worst case scenario. If you have a production MDM system and you find that a match rule is producing incorrect matches (false-positives) then you have some triage to attend to before you worry about changing a match rule.  First step is to shut off the rogue rule, next identify what records have been impacted by this bad rule and finally identify all subscribing systems that have been sent any of this incorrect data and inform the system owners of the nature and scope of the problem. Of course, this implies that you have the ability to identify matches by rule and that you can track the distribution of the information.

Consideration #2: Are you extending an existing rule to make it more accurate?

 

This represents the worst case scenario. If you have a production MDM system and you find that a match rule is producing incorrect matches (false-positives) then you have some triage to attend to before you worry about changing a match rule.  First step is to shut off the rogue rule, next identify what records have been impacted by this bad rule and finally identify all subscribing systems that have been sent any of this incorrect data and inform the system owners of the nature and scope of the problem. Of course, this implies that you have the ability to identify matches by rule and that you can track the distribution of the information.

Consideration #3: Are you prepared for the impact of the change?

 

If you are adding a new rule to catch duplicates that have otherwise been missed, then you will create a spike in the number of matches that will be distributed to connected applications or data stewards. Have you informed all stakeholders that may be impacted of the potential number of new records they should expect? Additional matches will increase the processing load for the MDM Hub the first time the match rules are executed much more than the minimal impact on normal processing. It may be necessary to run the new matches over a weekend.

Summary

 

An Enterprise MDM hub is an operational system that may impact almost every aspect of company operations. Changing MDM processing rules is not something to be taken lightly and should be subject to exhaustive analysis and testing. Companies that focus on the ease of changing a rule through a GUI are typically letting the tool overshadow the business process considerations of MDM.

Martin Dunn

Author

Martin Dunn was the co-founder of Delos Technology which developed the MDM technology marketed under the Siperian brand. The Delos MDM technology introduced many MDM concepts that are now widespread within the MDM discipline including a data steward console to adjudicate match results, opt-in synchronization, cell level delta detection and the concept of measuring trust.

Martin is now a partner with Gaine Solutions and continues to advance the techniques by which enterprise Master Data is managed.

Related Posts

Opt-in Synchronization

Opt-in SynchronizationNot all operational systems will choose to, or be able to, consume the changes made to master data in an MDM hub. The reasons for being out-of-synchronization may be technical, regulatory, political or economic but at some point it will be...

Business Process Improvements

Business Process ImprovementsThe analysis of master data and MDM processing logs can reveal interesting opportunities for business process improvements. We show how, as long as you collect the right data and know how to analyze it, you can drive significant business...

Ready to master data mastering?

Subscribe to our mailing list and we’ll send you courses, insights, product updates, and more. Get to know the ins-and-outs of your Gaine MDX platform, features, and solutions.