Should your glossary be connected to your data management software?

ESTIMATED READING TIME: 4 MINUTES

The data’s feeling like it’s a bit of a mess.
The warehouse isn’t really functioning well.
There are a few reporting issues that can’t be traced to a source.

People are getting frustrated.
Including the powerful people at the top.

So a data management project has been set up.
Lots of mapping, and data flow diagramming.
Lots of interviews and talking to subject matter experts.
More people get frustrated.

And an expensive piece of DM software is purchased.
It’s going to do fancy things and solve the problem.
It promises no more frustration.

The Transition Begins

The transition project begins. It’s a big job.
There’s a bit more frustration.
But at least the solution is here.

Sooner or later, those managing the data clean-up operation decide they need a business term glossary.

Which is true.
They do.

They need it to help define what the data is, and what it should be doing.
This is critical for getting the transition right.

It seems to make sense that the DM software glossary component should be sufficient.
After all, the glossary is there to help the data people get the data right.

Yet, if you’ve been in a company that’s gone down this path you may already have seen the common ending to this story.

**Spoiler Alert**
It’s failure.
Both glossary failure and transition failure.

Ultimately, those reports don’t get better.
The warehouse isn’t better utilised.
The frustration remains. Actually, it often gets worse, because hopes that things will get better have been dashed.

This isn’t good for staff morale. It isn’t good for business success.

Why Data Management Software Glossaries Don’t Work

Successful data management is necessary to ensure data is usable and available for business purposes.

That means it’s clean, it’s reliable and reliably there, it’s secure, it’s accessible and so on.

DM is valuable and necessary.

Data management software, then, has one goal – to enable the successful management of data.

But when the primary goal of your glossary is to support successful data management, you’ve missed the point.

If the glossary is developed to support the usability and availability of data, its purpose is to explain the data.
Not to everyone.
Just to IT staff dealing with the data.

Most business staff have very little reason to be directly involved or engaged with the nitty-gritty of data in this way.

But the glossary is trying to define language as used by business staff. To do this without the involvement of the business staff actually using the language is risky. But to do it without the business staff managing the up-keep and currency of those definitions over time, well that’s a fatal move.

In fact, business language needs to drive data; data shouldn’t drive business language!

In practical terms, the business staff should be driving the understanding of terms and the associated data, not IT.

If they don’t, it’s disaster for the IT migration or upgrade project. We’ve seen that train wreck a thousand times.

So I’ll say it again – business language (as defined and managed by business staff) needs to drive what happens with and in the data; data (and software) shouldn’t drive the business language.

Here’s a good reason why:
In big businesses, functional areas use the same terms but mean different things. Especially central terms like customer, policy or asset. This difference of meaning can also occur in the use of terms that are metrics.

If ALL functional areas are not represented in the definition writing, you’re really feeding your IT staff to the failure lions.

We’ve written a case study on how this differing meaning of one metric cost a large telco a lot of time and money. Read it here.
It’s a great example of how a lack of business-driven glossary work became a costly and (until we went in to fix things) an unsolvable reporting issue for the CFO.

One More Thing

When the glossary is created as a supporting document for DM, there’s commonly a belief that data and business terms have simple, 1-to-1 relationships.

That’s simply not true.
At least not all the time.

In our experience, “complicated” doesn’t begin to cover it.

Those relationships are more like a recipe.
A very long and specific recipe.

(we wrote about information management being like a recipe in previous blogs, read it here).

The Alternative to the Data Management Glossary

The best alternative to the data management glossary tool isn’t a tool at all.

It’s a whole new approach.

You need to take a big step back and realise that starting glossary work is just good business practice.
It makes good sense logically.
It makes good sense economically.
It makes good sense for business assurance.

It’s good information management.

And in fact, starting DM without doing this business information management part first is just plain crazy.

If the goal of data management is to ensure data is usable and available to business staff, then a decent amount of ground work to clarify the language around what those business staff do, and what they needs & what they want to be able to do, is a good idea.

With the foundation of very clear language, business staff can express their current actions, and their desires for future data access & reporting capability, really clearly and specifically. And IT staff can understand perfectly and deliver successfully.

TL;DR

The relationship between data and business terms is far more complicated than DM tool glossaries allow. At best, the glossary doesn’t illuminate much. At worst, the wrong numbers end up in reports and your business is still living with information issues, frustrating and costly work-arounds, and unseen risk.

Join the discussion on LinkedIn