Master Data Management: 10 aspects of MDM you need to think about

By Phil Marriott-Smith, Director of Data Management, Valcon

In the last ten years, data has risen to become the business world’s new currency. And if data is the new currency, then master data management (MDM) is its banker. So it’s vital you get your MDM implementation right. Here are ten factors to bear in mind before you implement an MDM solution.

  1. Looking beyond the surface when you select an MDM product: buyers often ask lots of questions, have multiple demos, and even ask vendors to build a custom demo prior to formally committing to an MDM product. The problem is that this only tells you what the platform does, not what it doesn’t do. This is because the questions and exercises are geared towards common use cases and do not delve deeply enough. For example, it is likely that an MDM product will offer a matching capability – but can it match on historic values, across attributes, weight attributes and anonymise values?
  2. Underestimating the need to educate: understanding MDM can be difficult, and even if your team understands the concept, effectively communicating the inputs and effort required from your business and subject matter experts can be a challenge. Failing to get buy in from key stakeholders due to a lack of MDM understanding can result in a lower quality implementation and increased rework.
  3. Understanding MDM product licensing: MDM product licence models tend to be quite similar and will normally be tied to data volumes, available features and the data connectors that are required. However, the nuances within these licence models can be significant, which can lead to unexpected costs, compromises in scope or design or the need to purchase additional licences.
  4. Choosing your infrastructure approach: MDM SaaS (software as a service) solutions are becoming increasingly popular and can be cost effective, avoiding infrastructure setup, management, and product installation activities. But they tend to have more constraints than PaaS (platform as a service) or IaaS (infrastructure as a service) implementations. You need to weigh up the advantages and disadvantages and if you’re choosing IaaS/PaaS, ensure you include infrastructure costs in your business case.
  5. Choosing the right implementation style: MDM implementation styles are not always well understood and different data domains often require different implementation styles. Some styles are more complex to implement and styles have different strengths and weaknesses. Integration is complex for a co-existence style, but it better aligns with existing systems and supports operational and analytical use cases. Whereas a registry style is easier to implement but has limited capacity to support data cleansing and operational use cases. Centralised styles are likely to be the most effective from a data governance perspective but are more difficult to align with operational business processes.
  6. Being prepared for what an MDM implementation reveals: when you initially ingest your raw operational data, and apply data quality and matching rules, then it is likely to reveal a substantial number of data issues. Some issues can be automatically resolved, but others will need manual stewardship. The manual stewardship and application of data fixes to operational systems can translate into significant effort, for which your existing teams may not have the capacity to accommodate.
  7. Handling data heterogeneity: MDM typically combines data from multiple operational systems, which often don’t use the same reference datasets or same formats for the same attributes. Complex attributes like address can be particularly problematic e.g. where one system may store an address on a single line, another across three lines and third with specific fields like house number, street, postcode. You will need to define and implement a harmonisation strategy to address the differences that operates on ingest and reverses the harmonisation on publish.
  8. Avoiding using internal global identifiers for your master data entities: it sounds like a great idea to introduce a master data global identifier that can be passed around systems and be used as a global identifier for an entity. However, we generally advise against global IDs, since you can only generate the ID in one place to avoid overlapping values and this can lead to a tightly coupled solution, which introduces complex dependencies. Using the golden record ID is not the solution, because the relationship between this ID and the source system records can change. Instead, you should let systems generate their own IDs and pass them to MDM and then let MDM become the register (index) for the linkages between records.
  9. The impact of data sparsity: MDM solutions often provide data profiling, data quality screening and data cleanse capabilities and it is worth spending time profiling your data to identify data quality issues, especially to determine where there is data sparsity. Since inaccurate or incomplete data can significantly affect your matching process and you cannot expect to build a high-quality golden record if the underlying source records are incomplete. You should also consider whether you will benefit from using data enrichment services, since they can help to plug data gaps.
  10. Use accelerators and templates where you can: solution providers will often have capabilities to help accelerate your implementation, such as: connectors for exchanging data with common systems; connectors for data governance cataloguing tools; plugins for common third party enrichments services; plugins for common data validations or DevOps tooling integrations. You should consider these, as they offer tried and tested methods for implementing common design patterns or requirements and can save a lot of effort.

It’s best to approach MDM projects with your eyes open. And there are some best practices you can consider before you select your MDM solution and start your implementation. It will really help to do your preparation – being forewarned where data projects are concerned, is being forearmed.

If you’re considering implementing a MDM solution and require some support or assistance, please take a moment to complete our short form here.

Want to learn more? If you would like to learn more about MDM, need help in comparing MDM vendors or architecting your MDM solution, or find out more about our accelerators, please email [email protected] and we’ll be in touch right away. 

Insights