Written by David vun Kannon Posted January 9, 2007
David vun Kannon was one of the first Co-Chairs of the XBRL Specification Working Group and has been an Editor of every version of the XBRL Specification. He is a Director for PricewaterhouseCoopers, LLP.
Master Data Management (MDM) has acquired a certain buzzword status in the last year or so. MDM is the recognition that there are critical corporate assets -- such as customer lists, which often exist as data embedded in an application -- that need management as a separate and distinct entity. This may be necessary for simple data consistency across platforms, or it may be a legal mandate.
One aspect of MDM is that several applications, or instances of the same application, have to share and synchronize metadata. Another is that this metadata has to be thought of as a distinct corporate asset that needs maintenance, just like a building or factory needs maintenance.
You may have noticed that I've already made a shift from master data to metadata. This is intentional. I'd like to leave behind the somewhat over-hip buzzword, and reframe the issues in terms of a larger context. That context metadata sharing and maintenance is one where I think XBRL can play a role in successful projects.
It's Data Warehouses All the Way Down
In the same spirit as generals always fighting the last war, many approaches to MDM focus on using data warehouse (DW) technology to address the metadata sharing problems of an organization. This often results in layers of data warehouses paralleling the organization of the business.
While this approach may be comfortable or familiar to IT staffs and the vendors that love them, it is not always appropriate.
First, consider that data warehouses were designed to handle extremely large numbers of transactions (data), and only secondarily the metadata necessary to support those transactions. The MDM problem is not a fire hose of billions of transactions that must be stored in one place so that they may be analyzed. Instead, MDM involves a few thousand to a few million rows of data that must be shared quickly across many applications and locations. DW fits MDM like a square peg fits a round hole.
Second, MDM is as often as much about the structure and relations of objects as it is about the objects themselves. Suppose you get an email: "Quick, send me your complete chart of corporate organization, including relations of ownership, management control, cross investment, directors and managers who hold multiple positions, tax domicile, etc, etc., etc."
Do you have a Brazilian subsidiary with greater than 50% foreign ownership, but management that is wholly or majority Brazilian? How fast can you answer the question? Can you answer before the regulator in Brazil fines your company? Is paying the fine cheaper than answering the question?
OK, by now you are crying for a metadata sharing solution that can capture the objects and relations (including business rules) of your master data and is cheap to implement, standards based, and easy to share with regulators around the world. And you know I have the answer to that cry XBRL.
This kind of metadata sharing is right in the sweet spot of XBRL. As mentioned in my post of several days ago XBRL: Living Up to Its Name, it's what made the FFIEC implementation of XBRL a success. This shouldn't come as a surprise. MDM is a problem of data transport and standardization of metadata. XBRL is a standard that operates at the data transport layer. Round peg, round hole.
Leave a comment