“I don’t have time to document metadata.”
If you’re in the data management or software industry, I’m sure you’ve heard this as often as I have. This is usually followed with a statement such as “I wrote the code!” or “I built the application!”, or some other thinly-veiled self-praise. What the person is really saying is “I’m too important to document metadata – I do the hard stuff.”
OK. Right.
Let’s apply this concept to any other industry outside of data or software. Perhaps, for example, a friend of mine had recently finished a novel. Excited for her, I ask “Great—what’s the title?” “It doesn’t have one,” she replies. Slightly confused by this, I ask, “Well, what’s the book about then?” She says nothing. “When will it be published?” Silence. “Where can I buy it?” Again—nothing—until she finally says “Look, I wrote the book—I don’t have time for these silly questions!” Needless to say, I won’t be buying this book very soon, and I’m sure she won’t be making the best-seller list. And I honestly might think my friend a little odd. Most people who create things love to tell others about it.
Perhaps a financial analyst is presenting the quarterly financial results to the board. Since results were low last quarter, the board has a number of questions. “I see the results for renewals are lower than last year – does that include the data from the new acquisition? What data sources did you use?” The analyst replies “I didn’t have time to write that down—I was building the report. Confused by this, the board then asks “What’s included in that total sales figure? Is that wholesale as well as retail sales?” Rolling his eyes, the analyst replies “I don’t have time to answer these questions—I built the report!” Needless to say, that analyst will not be presenting at the next board meeting. Financial analysts are required to show rigor: the lineage and calculations behind their work.
A good data management or software professional has some similar roles as those described above. On the one hand, like the author, we’re creators—building new and exciting things. On the other hand, like the financial analyst, we are in a very technical field that requires rigor and the need to show the lineage of and documentation for our work. Why, then, is metadata, which describes our creation and shows that it was done well, often seen as an afterthought or a burden?
Metadata describes the “who, what, when, where, and why” of data. Who created it, what it means, when it was created or updated, where it can be found, why it is valuable, etc. Skipping this step takes away much of the value from the hard work you’ve put into the project. If no one knows what it is, why they need it, or where to find it, your project is probably not the one that will get the attention of management and/or funding for next year. Unfortunately, I’ve heard too often the opposite reasoning by some data management professionals, who feel that not explaining or documenting their work is a form of job security. “If no one understands it but me, they can’t fire me, right?” Luckily there is a diminishing number who think this way.
Think of sales and marketing. These professionals spend years perfecting ways to describe their product in the ideal way – building their product’s “metadata”, so to speak. The salesperson’s elevator pitch or a marketing professional’s carefully crafted campaign are both designed to describe what the product is, why it’s needed, where to find it, who to contact for more information, etc. Those who are best at this are the most successful.
If you want your data management project to be successful, use sales and marketing as a guide. Build an elevator pitch for your data via well-crafted metadata. Tell everyone what it is, how well it was created, why it is needed, and who to go to for more questions. Documenting your metadata should be a key part of your successful implementation and rollout, not an afterthought that is overlooked or done in a cursory way. Highlight your data with great metadata, and you may be pleasantly surprised at the positive results that it yields.
