The role of master data management is back on the front burner again. When you think about it, it never really went away. Wherever you have data, you have master data. The care and management of that data is how the information system comes to represent the business context in which it operates. Master data is one of the ways of setting the standard for defining data and information quality. If the master data is out of line, then so is the quality of the information. The enterprise resource planning (ERP) revolution raised the hope of finally consolidating master data around a single transactional system of record. However, these hopes were dashed as proliferating instances of ERP applications were supplemented with customer relationship management (CRM), supply chain management (SCM), and analytic applications (data marts) corresponding to each. In short, the single version of the truth and its representation of the system of record continues to be a point on the horizon toward which our system development efforts converge, but which we never seem to be able to reach. If it is supposed to be a master file, then why are there so many of them? We are chasing a moving target. Meanwhile, the critical path to enterprise data warehousing continues to lie through the design and implementation of consistent and unified representations of customers, products and whatever other master data entities are needed to run your business.

A classic example of the issues that can arise with data warehousing and changing master data is the so-called rewriting of history needed when key dimensions (master data) change. If my sales hierarchy is joined to product sales to track product trends by sales region periodically, then the sales and product master data are an essential part of each sales data point. One hundred deluxe widget couplers are sold in Atlanta, Georgia, in the southeast sales region in the second quarter, which represents a company leading result. Send those guys to club. However, next quarter, the semiannual sales reorganization occurs. Atlanta, Georgia, is made a part of the south-central region. In the third quarter, only ninety deluxe widgets are sold in Atlanta, Georgia. Now the dilemma - if nothing else is done, then the south central region never had any sales in Atlanta, Georgia, prior to the third quarter, because that data point belongs to another region. Or, alternatively, the sales results must be recalculated - and the past rewritten - to capture the 100 deluxe widgets sold in Atlanta, GA in the second quarter as part of the south central region. This will make it possible directly to compare the results from the second and third quarter as part of the south central region - but at the cost of recalculating (and in effect rewriting) history. A third alternative is to maintain both versions of the sales hierarchy master data and dynamically recalculate on the fly. However, in either case, there is a trade-off. You can rewrite history in an opportunistic way and make possible historical comparison or lose the comparisons but be true to the sales hierarchy at a given point in time.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access