The first pillar, content, is not only the backbone of MDM, but also the foundation of any
data model. Master data content is usually enterprise-oriented and highly specific to
your business, relying on terminology that is often unique to your company.
What separates MDM from other technologies is that, in mastering the subject area,
it goes beyond the mere content of your data and presents relationships between
different data elements, including hierarchies and groupings. For instance, a “household”
frequently refers to a group of people living in the same location. Such a grouping
requires its own set of rules and definitions, as established in a data model. While a retailer
may merely group all the related people living at the same physical address, a bank, for
example, may only consider wage earners living at a given address. Again, it depends on
your business. Establishing the parent/child hierarchy within a given household may be
crucial for some businesses, such as insurance companies, but not others.
Similarly, MDM is able to support access rules to deal with the details of data flowing
into and out of the MDM hub. The delivery (or provisioning) of the data content and
relationship details to other systems means enforcing the rigor associated with security
and access policy at an individual data-element level to ensure that all rules and details
associated with data access is maintained. While most believe that data access or
linkage is limited to in-house or corporate systems, MDM can support any data source,
so integrating with third-party or external data is no more complex than an internal
billing system. As more and more data is available and linked, tight access control is
essential to ensure that data doesn’t fall into the wrong hands.
Because corporate information is always changing, mastering data also involves
supporting a robust change control component within MDM. Business data changes
in real-time, and an MDM environment must recognize which changes are acceptable.
A mature MDM hub understands when a data element change can be supported
in an automated fashion, or when it requires intervention from an external process
(e.g. another system, a data steward, etc.). Unlike traditional IT-based change control
methods that focus on application changes or business process changes, MDM focuses
on data value changes.
MDM also involves the actual processing of data, from basic matching and identification
to data correction and CRUD (create, read, update, delete) processing. Processing rules
contain the details for determining whether two records are the same. For example,
are customers Robert Smith and Bob Smyth the same? If so, should one of the values
be updated? If Bob calls and updates his address, should that change be propagated
throughout the other databases in the system, including the master record? Does it
matter if the address change comes from a third-party data vendor instead? Which
update should the system trust? And if it turns out that the data was incorrectly entered,
the data model should support unwinding the match to set the record straight.
This discussion of the five pillars is helpful in understanding the differences between
MDM and other strategic technology solutions, and will help to put the data model in
better perspective.
in reference to: Data-Modeling-and-MDM.pdf (application/pdf Object)
data model. Master data content is usually enterprise-oriented and highly specific to
your business, relying on terminology that is often unique to your company.
What separates MDM from other technologies is that, in mastering the subject area,
it goes beyond the mere content of your data and presents relationships between
different data elements, including hierarchies and groupings. For instance, a “household”
frequently refers to a group of people living in the same location. Such a grouping
requires its own set of rules and definitions, as established in a data model. While a retailer
may merely group all the related people living at the same physical address, a bank, for
example, may only consider wage earners living at a given address. Again, it depends on
your business. Establishing the parent/child hierarchy within a given household may be
crucial for some businesses, such as insurance companies, but not others.
Similarly, MDM is able to support access rules to deal with the details of data flowing
into and out of the MDM hub. The delivery (or provisioning) of the data content and
relationship details to other systems means enforcing the rigor associated with security
and access policy at an individual data-element level to ensure that all rules and details
associated with data access is maintained. While most believe that data access or
linkage is limited to in-house or corporate systems, MDM can support any data source,
so integrating with third-party or external data is no more complex than an internal
billing system. As more and more data is available and linked, tight access control is
essential to ensure that data doesn’t fall into the wrong hands.
Because corporate information is always changing, mastering data also involves
supporting a robust change control component within MDM. Business data changes
in real-time, and an MDM environment must recognize which changes are acceptable.
A mature MDM hub understands when a data element change can be supported
in an automated fashion, or when it requires intervention from an external process
(e.g. another system, a data steward, etc.). Unlike traditional IT-based change control
methods that focus on application changes or business process changes, MDM focuses
on data value changes.
MDM also involves the actual processing of data, from basic matching and identification
to data correction and CRUD (create, read, update, delete) processing. Processing rules
contain the details for determining whether two records are the same. For example,
are customers Robert Smith and Bob Smyth the same? If so, should one of the values
be updated? If Bob calls and updates his address, should that change be propagated
throughout the other databases in the system, including the master record? Does it
matter if the address change comes from a third-party data vendor instead? Which
update should the system trust? And if it turns out that the data was incorrectly entered,
the data model should support unwinding the match to set the record straight.
This discussion of the five pillars is helpful in understanding the differences between
MDM and other strategic technology solutions, and will help to put the data model in
better perspective.
in reference to: Data-Modeling-and-MDM.pdf (application/pdf Object)