prerequisites to a MasterDataManagement strategy [general]

Infosphere Master Data Management theory and best practices

Moderators: chulett, rschirm, falsehate

Post Reply
Posts: 229
Joined: Wed Oct 23, 2002 10:10 am

prerequisites to a MasterDataManagement strategy [general]

Post by datastage »

What are the prerequisites to implementing a master data management strategy? If a recent and formal L0 through L4 data quality assesment hasn't been done, would this initiative be set up to fail or can it still be a successful IT direction regardless of successful data quality management?
Byron Paul

"Strange things are afoot in the reject links" - from Bill & Ted's DataStage Adventure
Posts: 9
Joined: Tue Mar 16, 2004 12:06 am

Post by falsehate »

Keeping in mind that a dimension server manages reporting dimension hierarchies and their associated reference/translation data, but doesn't deal with actual transactional records, it is difficult to say whether or not data quality assessments are relevant to the success of an implementation. In my experience the proactive centralized management of reporting dimensions, when implemented, has forced an immediate and dramatic improvement of data quality accross the organization.

Several ETL vendors have touted technology that attempts to build reporting dimensions from columns such as profit center, account or product in transactional records. This attempt to bypass the business domain experts management of reporting dimensionality points to fundamental differences in opinion about the nature of the source of data quality.

Data quality tools are typically geared towards a bottom up assessment of the integrity of transactional data, while dimension management is typically a top down proactive data quality effort on the reporting dimensions only, without regard for account balances or any other quantity fields, which aren't relevant to management of the 'pure' dimension.

Therefore, I would say that while data quality assessments are extremely valid and useful from an ETL perspective, they are of little use in dimension management. In other words, the enterprise's desire to organize itself is not constrained by the lack of quality in a particular system or data file. (However, it shouldn't be overlooked that it's desire to measure itself may be dramatically impacted by this lack of transactional data quality!)

ETL developers typically benefit greatly from a dimension server implementation, because centralized reporting dimension maintenance and validation often means that ETL processes are receiving updated records in lookup tables for dimension translations prior to the new values being activated on source systems, like a new account in a ledger system, for example. This proactive dimension managment means that ETL developers can spend their time developing and tuning processess rather than responding to their pagers and chasing missing foreign key translation records for new accounts and profit centers, etc.
Post Reply