A very common starting point for producing tangible outcomes in a data governance programme is setting up a business glossary. The alternatives, or next/previous steps, for a business glossary were discussed in the post Metadata Musings by a Nerd.
First, in my eyes a business glossary (or whatever you call such a thing) is indeed a useful deliverable in its own right. In order to support a data governance programme you will need to add things besides definition of terms. One important element is documenting business rules as reported by Nikki Rogers at The University of Bristol here.
A business glossary should ultimately morph into full-blown metadata management or meet data dictionary and/or metadata repository initiatives that also may grow in your organization. What full-blown metadata management means was touched recently by Brian Brewer in a blog post called Gartner Says More Metadata. This post cites a blog post by Darin Stewart of Gartner (the analyst firm). The Gartner post is called Big Content Needs More Metadata.
How did you develop your business glossary?
- Did you start with a business glossary and then morphed into the data dictionary and metadata management discipline and lingo?
- Did the business glossary grow from the metadata management work?
- Is the business glossary just sitting there doing what it does?
Liliendahl on Data Quality 
Strongly agree with the idea of a business glossary as one of the foundational steps for Data Governance. If there is no common understanding of even the basic concepts across the silos of an enterprise, well, common governance is going to be challenging (to put it mildly).
The problem with initiatives about fixing glossary & metadata is that they tend to lead abstract, political, and too detailed argumentation. Even when the goal of documenting glossary is reached, it becomes a dead piece of paper in a SharePoint (or similar) archive.
I believe the success factor is to scope the exercise: to limit the glossary to the essential. But easier said than done: how to figure out what is “essential”? What do you say, Henrik?
Thanks for adding in Kimmo. I am a strong believer in agile approaches within many disciplines. You must have a vision embracing a broad spectre of capabilities and then implement in sprints with minor but essential deliverables. One feature of a business glossary is definitely that is a living thing. There must be responsibilities for continuous maintenance. The glossary should support related capabilities and definitely be a reference for more technical data dictionaries and metadata repositories as for example mapping the business glossary to data elements in the current system landscape. The business glossary will also define elements that may not currently be held in internal databases, but could be used in spreadsheets, looked up on the internet and even only exist in none digital form for now.
What I find useful about a glossary is the high level information, not the low level. For example: is a prospect counted as a customer? I have seen it argued, successfully, both ways. This will affect the customer count report and an organization should have consistent terminology for this. Where I don’t see it useful is on self defined terms. “First Name” for most geographies is self explanatory. I also have a hard time seeing large value in environments with multiple COTS. If SFDC manages a field in a certain way, and SAP captures that information a different way, then a metadata tool can only record the differences. A company will not be rewriting SAP, SFDC, Oracle or whatever to reconcile the difference.