Why Terminology is Important

We ask the questions that people having been avoiding for years while they were trying to look smart.

I read an article today from our respected colleague, Yaaqub Mohamed about the importance of data analysis as part of a good analyst’s tool belt. Well that is not exactly how he put it, but you get the gist.

Anyhow, it got me to thinking about another type of data that often goes unnoticed until it is far too late to even say, “Oops!” Yes, yes I’m speaking of nomenclature and that involves the identification of terminology and the definitions and aliases used to capture meaning.

It doesn’t seem all that important, but it can be as dangerous as a missed stakeholder with a bad attitude and political agenda if not properly handled. Allow me to paint you a scenario to consider.

I work for an organization that started with one division and it ended up buying three more along the way. We all do the same thing, but we do it in different states under different legal guidelines and the like. Each division had been in business for a number of years prior to being merged with the others. So, it stands to reason that each division’s employees does things a little differently while achieving the same goal. Along with that, each division refers to the same entities by a different name. Imagine trying to build an enterprise application with this standing in the way. I cannot begin to tell you how interesting the JADs are before we realize that there are either four names for the same thing or one definition applied to four disparate terms.

It would seem that a glossary would cover the issue and we could move on with our lives, but that requires people to read it. When was the last time you took the time to look up a word that you didn’t understand? The real issue rears up with usage, context and general comprehension during conversation. Most of the time we can figure out context while holding conversations and can even pick up an accurate meaning periodically.

However, when there are 30-40 people arguing about things while using often very similar, yet still completely different terms, the last thing that people seem to do is whip out their trusty glossary. Most of us go with the flow, so we don’t appear stupid, and that is about the stupidest thing we could do. If terminology is not clearly and consistently understood, there is a huge margin for error in the solutions that you as analyst recommend to your audience. If there is more than one audience and they aren’t on the same page, then guess what happens? Yup! Think about the error conditions of implementing business rules if there is not clear terminology for governing the entities of the organization. Migrate those problems into code and you have real issues.

The analyst has a grandstand seat to watch these struggles in order to understand trends between stakeholders, and plays an important role in bringing people together to talk and listen to one another in order to find common ground in terminology. Failure to do so can lead to costly, yet surprisingly simple errors. Here are a few things you can do…

• Identify your terms. As you take notes and write documentation, pick out the domain terms that are repeated or singled out as words that have meaning to your stakeholders….especially those that can have multiple meanings.
• Make a simple glossary a mandatory part of your documentation. Even if everyone speaks the same language (meaning dialect) and calls an orange an orange….your writing will capture that fact. Eventually, someone will be hired who refers to an orange as a lemon and you will have the baseline established.
• Ask if you don’t know what something means! If anyone is going to ask stupid questions, it better be you functioning as an analyst. That is why you are there…and don’t forget that! We ask the questions that people having been avoiding for years while they were trying to look smart. Why do you think they need analysts now?
• Validate your terms and definitions against the business rules, whether in text or code.
• Validate your terms and definitions with ALL stakeholders.
• Define all known aliases to bring mindsets and conversation together.

In summary, take a little time to make your life and that of your stakeholders and developers by calling out variations in the words you hear used to describe the domain that you are working in. Take ownership of controlling this knowledge, and put it to use as a part of your project. You will not believe all the use a good set of terms can have, not the number of times others tell you how great it would have been if they had it previously.