Looking back at some of my Informatica Perspectives posts over the past year or so, I reflected on some common themes about data management and data governance, especially in the context of master data management and particularly, master data models. As both the tools and the practices around MDM mature, we have seen some disillusionment in attempts to deploy an MDM solution, with our customers noting that they continue to hit bumps in the road in the technical implementation associated with both master data consolidation and then with publication of shared master data.
Almost every issue we see can be characterized into one of three buckets:
1) Reference data issues, associated with misalignment of commonly-used master data sets, conceptual data sets, values domains, and various mappings across those ideas. For example, one business application defined US States to include only the 50 states and the District of Columbia, while other applications will include Puerto Rico, the Virgin Islands, Guam, and Samoa as values within the US States data domain.
2) Structure issues, which often relate to differences in the source data models for similar data entity concepts (at the data element, table, and entity relationship levels) as well as differences between the source models, the master data models, and the downstream applications.
3) Semantic issues, in which isolated “meaning” differences that are specific to an application cause problems in aligning data entity relationships into a common model. As an example, one of our clients is trying to create a master customer database, except that one source is the marketing application, and while the items in that data set are called “customers,” many are actually just “prospects” and have not yet committed to purchasing a product.
These are actually three sides of the same coin (funny looking coin, though ;-) ) that reflect program implementation stalls due to master data modeling issues. It turns out there are two “philosophical” approaches to master data modeling. On the one hand we have the “pre-packaged” approach, in which the MDM vendor provides a set of core data models for each common data entity such as customer, vendor, contract, product, etc. These models are often derived from universal-style, hierarchical/object-oriented models, and are tweaked to fit into the architecture of the deployment site. This approach basically comes bundled with a set of defined services for accessing and updating master data attributes and objects. In the other approach, the characteristics of (and relationships among) master data models are driven by the specific needs of the business (and is consequently referred to as the “business model-driven” approach). In my next post I will provide some additional details about the differences between the approaches. I will also be talking about this on a March 20 TDWI Webinar, “Is Your Approach to Modeling MDM Fixed or Flexible?”
Almost every issue we see can be characterized into one of three buckets:
1) Reference data issues, associated with misalignment of commonly-used master data sets, conceptual data sets, values domains, and various mappings across those ideas. For example, one business application defined US States to include only the 50 states and the District of Columbia, while other applications will include Puerto Rico, the Virgin Islands, Guam, and Samoa as values within the US States data domain.
2) Structure issues, which often relate to differences in the source data models for similar data entity concepts (at the data element, table, and entity relationship levels) as well as differences between the source models, the master data models, and the downstream applications.
3) Semantic issues, in which isolated “meaning” differences that are specific to an application cause problems in aligning data entity relationships into a common model. As an example, one of our clients is trying to create a master customer database, except that one source is the marketing application, and while the items in that data set are called “customers,” many are actually just “prospects” and have not yet committed to purchasing a product.
These are actually three sides of the same coin (funny looking coin, though ;-) ) that reflect program implementation stalls due to master data modeling issues. It turns out there are two “philosophical” approaches to master data modeling. On the one hand we have the “pre-packaged” approach, in which the MDM vendor provides a set of core data models for each common data entity such as customer, vendor, contract, product, etc. These models are often derived from universal-style, hierarchical/object-oriented models, and are tweaked to fit into the architecture of the deployment site. This approach basically comes bundled with a set of defined services for accessing and updating master data attributes and objects. In the other approach, the characteristics of (and relationships among) master data models are driven by the specific needs of the business (and is consequently referred to as the “business model-driven” approach). In my next post I will provide some additional details about the differences between the approaches. I will also be talking about this on a March 20 TDWI Webinar, “Is Your Approach to Modeling MDM Fixed or Flexible?”
0 comments:
Post a Comment