Master Data Management Part 2
What is it and what does it mean for you?
Issue: 15.2 (March/April 2017)
Author: Craig Boyd
Author Bio: Craig Boyd is currently a data architect for a major fashion retail brand. But in his 20 years of IT experience, he has been everything from a PC Technician, iSeries System Administrator, iSeries Programmer, Sr. Technical Lead, Data Modeler, Data Architect, Oracle DBA, BI Consultant and Solution Architect. He lives in the great state of Texas with his wife and two kids.
Article Description: No description available.
Article Length (in bytes): 14,271
Starting Page Number: 74
Article Number: 15208
Related Web Link(s):
Excerpt of article text...
In this month's column, we are going to continue our discussion of Master Data Management (MDM). In the last column I tried to give you a brief idea about one small aspect of MDM. After the publication of the column, there were some folks on the forums who were kind enough to point out that what I had talked about in the column was really only a small portion of the whole topic. I would, of course, like to thank those folks for doing that and I would also encourage any of my other readers to let me know if they feel like there is more to a particular topic that I should address than I have done. I appreciate feedback and, anyone kind enough to send me their thoughts on something I have written, I will take seriously enough to give an appropriate reply.
In the last column, I discussed one of the more common issues that MDM is used to address as well as a couple of different design patterns. In this month's column, I am going to step back a little and discuss some of the other aspects of MDM. I would encourage you to glance through last month's column because I will be referencing it throughout this column. As I should think is obvious because of a variety of limitations, I will not go into any of these in any great detail, but will try to explain them sufficiently enough that you get the idea or feel for what they pertain to and why they are important or relevant to MDM.
In the previous column, I gave you the following definition of MDM: Master Data Managment is defined as "a comprehensive method of enabling an enterprise to link all of its critical data to one file, called a master file, that provides a common point of reference. When properly done, MDM streamlines data sharing among personnel and departments" (
This definition was sufficient for the content of that article, but it is lacking in completeness. Therefore, in the context of this column and in my effort to briefly touch on some of the other aspects of MDM, I offer the following more complete definition: "Master Data Management (MDM) is the framework of processes and technologies aimed at creating and maintaining an authoritative, reliable, sustainable, accurate, and secure data environment that represents a 'single and holistic version of the truth' for master data and its relationships, as well as an accepted benchmark used within an enterprise as well as across enterprises and spanning a diverse set of application systems, lines of business, channels, and user communities." (Berson, Alex and Dubov, Larry (2011).
Master Data Management and Data Governance, p. 12)
There are three large areas of MDM that I will touch on in this month's column: Data Governance, Architecture, and Compliance (which is made up of security, privacy, and regulatory compliance).
...End of Excerpt. Please purchase the magazine to read the full article.