SAG_Social_Media_913x560_Ebb-and-Flow_Meme3_Aug15In the last of our three-part data governance blog series, we discuss the ongoing controversy over MDM data modelling; an art form which ebbs and flows in popularity.

It comes as no surprise that any system that creates and manages master data must organize that data through data models. Whether created independently through modeling tools or presented as fait accompli by enterprise resource planning (ERP) modules, business applications need data models to standardize the importing, exporting and reporting of business information. I have said before that data modeling is a major enterprise discipline and maybe – if we get a bit emotional – even an art form.

But before we get too carried away with admiration for data modelers, who make up a significant portion of most large IT departments, we should remember the process-oriented side of data modelling which requires input from business. Whereas the IT department is tasked to find and evaluate the best MDM technology platform for the job, it is also critical that IT and data modelers work closely with the business side.

Data modelers should help businesses to flexibly adapt their models to business IT requirements. If the focus is too data-centric it can restrict the implementation of growing requirements for new business model attributes. And, if they don’t help manage disparate application data models across the enterprise, that’s even a bigger problem which is the clarion call for MDM.

The conundrum lies in the choices your organization has for implementing MDM; should you use pre-existing corporate data models for an MDM implementation? Or should you choose domain-specific models/templates, provided by a vendor?

With a pre-existing model you can utilize your corporate domain expertise, maximizing in your previous investments in data modeling tools and data modeler training. This helps you to maintain some industry differentiators in your modeling.

If, however, you choose an out-of-the-box, vendor model and templates, you can accelerate your MDM implementation, supplementing a possible lack of domain expertise, and benefit from ready-to-go, canned reports.

Vendors who provide out-of-the-box, specialized templates in order to ramp up MDM projects can prove to be a time-saver. For example, financial services have very specific requirements around both data models and hierarchies, collecting both internally- and externally-validated information for a Security Master. After all, why needlessly attempt to replicate industry standards for modeling when an MDM provider has already done it for you?

But most industries are constantly changing and churning— and what looks initially like an efficient accelerator in terms of modeling could rapidly require adaptations and extensions to support real-world business changes.

Maybe the answer lies in using both methods; since most MDM vendors support the ability to change and extend MDM data models including provided templates, the issue of your organization being compelled to support an out-of-the-box, vendor-established data model will sooner or later be moot. Your own business data model could be the driver for an MDM implementation, with your cultivated, best practices data model imported or “dropped” into the MDM system. Sound good?

We have given you the reasons for seeking process-driven MDM, along with some tips to speed you along the way and an analysis of some of the decision needed for data modelling. Here is a white paper that can tell you more about how to apply process-driven MDM to your data-quality challenges.

For more information please download our free white paper: A Primer for Process-Driven Data Governance

Leave a comment

Search B2B

Most Popular Blog Posts


Connect with us!