David Loshin recently asked leaders from four master data management vendors to do something that you might think would be pretty simple: Explain what defines data as "master data?"
With these things, there's always the simple answer-the sound bite, if you will - and then the complex, but more useful, answer. Of course, the panel came back with the simple answer first, which Loshin summed up as, "data concepts that 'are important' to the business and are shared by two or more applications."
It took Loshin three tries to make progress on the more complex answer, which really is about how organizations figure out what constitutes their master data, as opposed to their more mundane data. The panel ultimately settled upon a fairly predictable answer - analyzing your data so you know how it's used, who's using it, which applications are using it, and so on.
But you can tell from reading Loshin's post that he's not quite satisfied with the answer, and I know how he feels, because I've had my fair share of interviews that waffle between simple sound bites to more complex, but still overly general.
I also had to smile, because it turns out, a year ago, I asked Loshin a similar question - what is master data and can the definition differ. I actually wanted the definition, not the process for defining it - alas, I wasn't swift enough to ask that. Fortunately, he's better at answering questions than asking them, because it only took one try. His explanation of master data:
"There have been many definitions proposed out in the general literature, and I have always been careful to say that I am providing a "description" of what I believe MDM incorporates rather than a definition. Master data objects represent the core business concepts used in the different applications across the organization, along with their associated metadata, attributes, definitions, roles, connections, and taxonomies, such as customers, suppliers, parts, products, locations, contact mechanisms."
He then went on to define master data management and how it can fit in with an IT strategic plan.
How organizations define what is and is not master data is an excellent question, really, and grossly under discussed, consider how foundational it is. In fact, I don't think I've seen anything on the topic-everybody just skips straight ahead to master data management. As an example, this week, Information Management published a piece on the MDM maturity model, which is exactly the type of piece you would think would mention this process. It outlines five levels of maturity and includes an excellent chart, in a .pdf, outlining how integration, governance and so on evolve as MDM matures. BUT, there's no level that simple includes "define your master data."
Perhaps we can assume that's a zero-level task?
As it turns out, defining master data for your organization may not be as hard as you'd think. Marty Mosely, who participated in Loshin's panel on behalf of IBM's Initiate Systems, saw Loshin's post and responded with a much more useful answer.
First, he explains, defining master data should be a top-down exercise. He suggests leaders start by identifying which "subject areas" define their data-and he says they're usually able to do this quickly and without profiling all the data. Then, they should consider whether the data in each subject matter matches three criteria:
"I've found that most organizations can easily agree which of those subject areas fall into the category of 'master data,'" Mosely adds.
I suggest you read the full post and the comments. Hopefully, by the time you do, more MDM experts and leaders will have chimed in with their thoughts on this critical, but under-discussed, question.
I did find some older, useful conversations about master data management, including this thorough Knowledge Integrity blog post, another BeyeNetwork piece written by, appropriately enough, Loshin, and an MSDN Architecture Center article that discusses identifying master data. I noted with interest the MSDN piece points out that not all master data needs to be managed by MDM. But all the articles were from 2006. They're still useful reads, especially for technologists, but they focus primarily on defining master data, with little information about how you can define your own master data.