Business Glossaries – the pointy end of metadata management

A recent thread on LinkedIn raised the issue of implementing a business glossary (in particular relation to using IBM’s Business Glossary tool).

I generally try to avoid commenting on any particular vendor’s products in this blog – as regular readers will know, I’m much more concerned with all the joys and frustration of the human aspects of Information Management! However, the LinkedIn discussion raised some interesting questions on the topic of “business glossaries” and metadata management more generally, and I think these are worth exploring and summarising.

The first thing to note is that the key issues of successful business glossary implementation aren't related to the technical deployment of the tool anyway. As with all Information Management capabilities, they are cultural, societal, behavioural, process - i.e. human challenges (that is true whether you are dealing with data quality, master data management, Information Asset Management etc.). The overall approach to Data Management and Governance needs to be given due consideration - who is responsible for data definitions and business rules, who has the decision rights, how do the definitions get maintained, management and published etc.)

The key purpose of a “business glossary” is that of human communication and collaboration – to exchange business-level understanding and interpretation of informational terms. A business glossary (sometimes referred to as "business dictionary", “business metadata”, “business vocabulary” or “business lexicon”) collects terminology that expresses business concepts in the language of the end-user, with the aim of collating one consistent set of terms that are commonly understood by the user community. That’s hard enough!)

Getting people to agree on words & definitions is difficult. Unfortunately life isn't that clean cut. Even just collecting as many words/terms/phrases/acronyms as you can grab and examining the different uses/definitions/conflicts can be time consuming.

When I was at UNSW we ended up collecting over 1500 terms, which one way or other resolved to about 400 groupable items (e.g. there were six different ways of establishing whether or not we counted someone as a "student"). 

Resolving all of those contentions, discrepancies and ambiguities in one go was way too hard for most people to get their head around, let alone show any interest!) So we focussed on one subject area - in this case, Staff/HR data definitions - which was a high priority as we were in the process of re-implementing our HR admin system.

One common question that was asked very often was “How many staff do we have?” This invariably led to much wailing and gnashing of teeth as people scurried around, frantically trying to answer the question, only to come up with multiple different answers, none of which corresponded with any other answer.

Of course, the challenge was that there was no agreed understanding of what anyone meant by “How many”, “staff” and “have”!

At UNSW, we had a working party of 5 full-time team members, supported by a part-time stakeholder group of approximately 30 nominated business representatives. (For some comments about the "consultation culture" at the university, see my interview for DataQualityPro.) 

We settled upon approximately 80 agreeable terms, which also included some significant re-thinking of business concepts in some cases e.g. we had to split the generic and idea of someone having "contract" into the concepts of "employment status" (permanent vs temporary), "employment type" (fully employed vs fixed term vs contract vs casual), "payment arrangement" (paid vs emeritus vs conjoint/volunteer) etc. 

Just for the "Staff/HR" subject area, it took over six months to get the definition of terms resolved. We than had to start on the process of cleaning the actual data, ready for migration to the new system... Whatever you're doing, patience is a virtue!

It’s also worth noting that the issues of identifying, validating and communicating this common business language are very different from (though related to) the more detailed questions of data modelling, integration, traceability, integrity and auditability enforcement which might be considered the realm “technical metadata” (and I’m using the word “technical” very advisedly here to mean any aspect of metadata management that isn’t immediately end-user facing!)

By the way, I’m not suggesting that “business metadata” and “technical metadata” are separate – indeed, it’s vital that they integrate and correlate to/down and bottom/up.  Together, these will form the core body of knowledge that defines the existence of the organization. However, in order to make things manageable, it is useful to think of them as different views of the same thing, dependent upon role and purpose.

In my experience, if you want to be successful in implementing an Information Management environment, it is absolutely vital to address the human, cultural and societal factors that make for a successful outcome. Build organisational capability and resilience for Information Management as a set of foundational disciplines. Think about the accountabilities, responsibilities and process controls that are required.

Hint - Enter into a project naively, and you will fail. don't buy the tools unless you are prepared to deal with the human factors.