Many organizations use a half way point of their fiscal year to analyze results of their efforts and decide whether their strategies are working or if changes need to be made. Informatica just passed its half way point for our fiscal year and I had to determine how many Master Data Management (MDM) projects included Informatica products for data integration, data quality, and identity resolution.
While I can’t disclose how we did, I can tell you this, it’s difficult to say exactly which client purchases were for use in an MDM project or not. Of course there are some easy ones to identify as MDM. The client purchased PowerCenter and Identity Resolution to build a Customer Registry. Or, the client purchased PowerCenter and Informatica Data Quality to load high quality data into an Oracle Universal Customer Hub. Clear cut, that client is using Informatica for an MDM project.
But what about the not so obvious examples? For instance, the client says they are doing an MDM project, but they are cleansing and loading customer reference data into a data warehouse. Is this Master Data Management? They are applying some data stewardship principles to ensure that they have matched customer records across systems and based on the best information available have created a “golden record” for that customer. Sounds like MDM, right?
But how is this second scenario viewed from a data housing perspective? The client is cleansing and matching customer records to load into a data warehouse ensuring that the dimensional data is accurate and complete. Sounds like data warehousing, right?
So the question is this, are you “doing” MDM if you are storing your reference data in a data warehouse? A CRM system? A custom database? Or are you only “doing” MDM if you buy one of the MDM products reviewed by the likes of Forrester or Gartner?
Or to put it another way, is MDM an activity that an organization undertakes to ensure accurate and complete reference data or is it a product that you buy?
What do you think?
3 Comments
Like many other areas (e.g. SOA, EA, …) MDM is a practice not a product. I see many of our companies focusing on getting consistent, up-to-date views of supplier information. Some use MDM products but many do not. Invariably defining the process and business requirements for getting clean master data is the hardest part. Many customers succeed in implementing the solution without an MDM product.
That is not to say that the MDM products can’t make this process much easier. Large, complex environments often demand more complex tooling.
I agree with Dave that MDM is a practice/process and not necessarily a product. MDM initiatives at any given organization have a context, purpose and objective behind them. Depending upon the business drivers behind doing MDM, scope of the activities done to get to MDM could differ from organization to organization. As pointed out (earlier in the blog) some organizations might choose to build a clean master record before proceeding with building other components of master data into that master data set, where as other might go full tilt.
Depending upon the organizational data size and variability of that data, one might be able to build a master data set (For customer, products, suppliers, employees, competitors or any entity they are interested) in as simplistic tool such as excel where as others might require fully fledged data warehouse infrastructure and all the tool sets available.
In summary (in my opinion) MDM is an activity that an organization undertakes to ensure accurate and complete reference data. It is definitely not a product that you buy. (Product is possibly a means to the end goal of MDM)
Vish Agashe
This is pretty much we we are seeing as well. Organizations are first asking the question “how should we approach the management of our master data” and once they have a good understanding in place, they then ask the question “what technologies will help me”.
With this in mind, many organizations are finding that they need a foundation based on data integration, data quality, and identity resolution. From there we are seeing a 50/50 split between those that purchase a packaged MDM application to complete their “MDM stack” and those that decide to build their own MDM application.