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.

Information Management Quote of the Week 19/07/14

“Do not quench your inspiration and your imagination; do not become the slave of your model.”

(Vincent Van Gogh)

See also:

“Stupid is as stupid does...”

How to really learn the lessons of your mistakes, and turn them in to foundations for success

How often do you run a “lessons learned” session after the completion of a project? Good practice would have us carry out such an evaluation following any significant piece of work – and collective learning from previous experiences has got to be a good thing, right? 

Well done you.

Now ask yourself this – how often do you actually apply the learning that was so heart-wrenchingly drawn from the exercise in group suffering and torment that is a “Project”? Or do you put the “lessons learned” document in the project filing cabinet, never to be seen again (and where the lessons will quickly get forgotten)? Not feeling quite so self-satisfied now, hmmm?!

As Forrest Gump put it, “Stupid is as stupid does.” 

If you’re forever repeating the errors of prior experience, then go figure… So here’s my tip if you don’t want to repeat the failures of before.

Don’t do a “Lessons Learned” session at the end of a project.

(Pauses for a moment to allow the gasps of shock and indignation to pass...)

I suggest incorporating a “Long Hard Look” exercise at the start of a project phase as part of project initiation and planning.

These sessions should involve a focussed sub-group comprising of key stakeholders and the project team and will focus on answering three key questions:

• NEW OPPORTUNITIES: What should we start doing that we currently don’t do?
• INHIBITORS TO SUCCESS: What are we currently doing that should we stop doing?
• SUSTAINED SUCCESS: What are we currently doing well that we should keep doing?

You then need to build the learning points from the “Long Hard Look” into your project principles and approach. This will help you to create the manifesto or statement of intent that will drive the overall project team towards as successful outcome. (See also Jim Harris’s excellent article, “Data Governance, Commander’s Intent and Semper Gumby,” for more on this).

Regular “Short Hard Look” health-checks during project progress are also a good way of ensuring that the project remains on track to meet its outcomes…

"What you should know about" quickie

Not strictly "Information Management." But I thought this "quickie" was worth sharing in the wider context of information sharing and evidence-based decision-making:

Sourced from Facebook. With thanks to Alex Matthews, Sciencegasm and IFLScience. 

The information about all these topics is freely available. Whether you choose to seek it out or not is your choice...

Enjoy

ADD

Information Management Quote of the Week 11/07/14

“Respond intelligently even to unintelligent treatment.”

(Lao Tsu)

See also:

Dispelling the MDM Myth, Part 2

If you don’t want to confuse, be careful of the terminology you use!

Wow! When I posted my article “Dispelling the MDM Myth” last month, it seems like I really opened up a can of worms – mostly in a good way.

While it was easily the most popular blog post I wrote last month (getting nearly double the number of hits that the next most read post received), what became apparent through various group discussion threads on LinkedInis that the “MDM” acronym isn’t nearly as well understood or universally used as I had anticipated. (e.g. here, here, here and here) There were various comments to the effect of “what do you mean by that”, “please stop using unfamiliar terms” and “I don’t understands” going on. (Bear in mind that the groups that I had posted to are all focussed on the practitioners and professionals within the Information Management & Data Governance community, rather than being more general business user groups where I might have expected a higher level of unfamiliarity.)

Lesson for me? Make sure you always do a “Humpty Dumpty” and define your terms whenever you use a piece of jargon, even if you think your audience is totally familiar with the domain! If nothing else, it ensures that you’re all on common ground and discussing the same thing within that topic. e.g. one commenter identified that in certain circles, “MDM” can refer to “Mobile Device Management”.

(Aside: all this also made me wonder whether there is also still confusion when it comes to  terms such as "Business Intelligence" (BI), "Data Warehouse" (DWH), "Customer Relationship Management" (CRM), "Enterprise Architecture", "Cloud Computing", "Big Data" etc.?)

Anyway, with Humpty-Dumptyism in mind, I thought I should clarify my general overview of what I take Master Data Management (MDM) to mean - if nothing else for the sake of disambiguation within my own mind!

• The term "Master Data Management" (MDM) is a well-documented and accepted phrase within the Information Management & Data Governance arena as a generic catch-all for a wide range of complex and inter-related disciplines affecting the processes, methods, architectures and tools of administering core categories of descriptive and categorising reference data. It is prevalent within the Information and Data Management sector and the acronym is in wide use in our industry. (Web sites such as those by IAIDQ, MIKE2.0 and DAMA are useful to gain a broader understanding). 

• The originating "golden record" of ANY data record should ideally be managed according to principles of data mastery, and on that basis "Master Data Management" would refer to the disciplines of curating the originating source of all such data, with every other usage of that data becoming an integrated and dependent read-only copy. 

• However, the term “Master Data Management” in its current common usage focuses on the disciplines of co-ordinating the data values and member records for key sets of "master" reference data (the Product list, the Customer list, the Locations list, etc). These lists of reference data records get re-used as look-up data sets in multiple transactional systems - they are what gives each transaction record it's context and meaning. (In data warehouses and Business Intelligence solutions, the Master Data sets become the member records within the "Dimension" tables, while the transactional records become "Fact" tables.)

• Unfortunately, very often these "master" data sets don't get co-ordinated terribly well - each transactional system can end up maintaining a local copy of the data, and we end up with inconsistency of the data. This can happen even if the core "enterprise" data model which defines the expected structure of the data is well defined and the metadata structures for all the systems are properly maintained.

• Coordinating and maintaining the Master Data sets requires specific process and organisational disciplines that are part of the business function, not IT.

I would make the point that the summary of "MDM" that I've offered above reflects how I perceive the term to be in general and pervasive use across the industry and in particular as appropriated by the software vendors. (i.e. the management of common reference & contextual data sets only.) Depending on your point of view, that may be unfortunate, or even "wrong", but it is how things are. 

In that respect, it's not really "my" definition - and anyone who thinks I've got enough influence within the Information Management sector to affect a change to this received usage is A) significantly flattering me and B) delusional!

As I implied in my original post, I think part of the challenge is that the technology vendors will always appropriate any fashionable term and mis-direct it to fit their own particular agenda - which means no standard understanding and we have an Information Management "Tower of Babel" on our hands. Once we go beyond a simplistic and generic understanding of the discipline as a whole, different software and services vendors tend to use such terms to mean subtly different things dependent upon their own purposes and tend to focus on the technology aspects of data management, rather than dealing with the human elements. 

We've seen this with "Business Intelligence", we've seen it with "Big Data", we're now also seeing it with "Data Governance" - which I've seen used to describe anything and everything from ETL mapping tools, metadata repositories, security management software and even just data storage.

In my view, purchasing a software product will (almost) never a panacea end to all your problems - it will be the starting point only. The "80/20" rule applies pretty well - 80% of the effort, cost and general heartache for any successful deployment will relate to "human" elements (organisational, educational, cultural, behavioural, process/procedural) and 20% will be about technology delivery.

In my 20-plus years of doing this schtick, I've encountered very, very few product vendors (and all-too-few services providers) who take this mindset into a project. In the MDM space, the French business Semarchy are one such business, while in the Data Governance area, Collibra seem to be saying many of the right things (which is reflected in Forrester's latest Data Governance market analysis). IBM's Information Management division are now getting there, but it's still patchy. After that, it seems to be tools and features all the way...

If I was to be REALLY cynical (surely not...), then I'd offer that from a project management perspective, it's the human elements that bring almost all the risk, so as someone bidding to implement a solution for a client, the very first thing that you'll want to do is manage your risk by excluding any human factors from your contracted scope. It also means that the "core cost" of a project will appear much lower - which is great if you're trying to get a Business Case past an unsuspecting Executive group, but hopeless when it comes to the reality of getting anything done. Result - project failure.

(See my recent discussion paper on Distributed Data Quality for some alarming statistics on how many information management projects fail to meet expectations):
http://www.informationaction.blogspot.com.au/2014/03/new-white-paper-distributed-data-quality.html)

As an industry, we've collectively bought into this "Emperor's New Clothes" delusion. Clients need to be less naive, vendors need to be more ethical.

So in summary - if you ever come across anyone who does take a "humans first" approach, treasure them and don't let them go!

Key message #1: beware the vendors!

Key message #2: All of us within our industry have a responsibility to contribute to the ongoing education and change process. We do what we can, and we all benefit if we help each other.

I really hope that’s now cleared everything up!