Conceptual modelling and the Business Dictionary

The human mind and complex situations

When I have 3 to 5 items in a checklist, I've no problem remembering them. When there are more than 7, it's harder. To make it easier, I usually categorise the list into several groups of similar items. This is natural to any human mind older than 6 years of age (studies show that when children reach that age and discover this categorisation technique they just love to try it again and again). It's also natural to continue this categorisation system when the groups that've been created become too big themselves. We create sub-groups of groups and sub-sub-groups and so on - and a hierarchy comes into existence.

Hierarchies (or tree structures) are clear to us, simple and understandable. We like them, we want them and look for them. The most frequent pre-sale question when we offer to create a company dictionary is whether there'll be hierarchies of terms in it. We understand this request, we can create a structure of links between terms to provide hierarchical relations, but we think we have an even better solution.


The curse of hierarchies

Imagine a simple example of a compound term, "retail customer". Usually there's a hierarchy of terms in a business dictionary related to the general term "customer", e.g. active customer, deactivated customer, affluent customer, retail customer. Besides that there'll also be another hierarchy related to "retail" - retail price, retail agent, retail customer, etc ...

So here is the natural problem with hierarchies in (almost all) complex situations: many items ought to belong to several hierarchies and to exclude them from all but one will always lead to very artificial results ...


A simple answer to a complex world

We, at Semanta believe that the natural formalisation of relationships between terms should be a network (not only a tree). This is what we consider as a suitable alternative for a business dictionary. We call these networks, "clusters of terms".

What is a cluster of terms? Clusters are very similar to conceptual models. They identify the highest-level relationship between terms. We always represent them through a diagram, e.g.



What's useful about these diagrams?

  • There are boxes linking the terms defined in a business dictionary, however, there is no need to define all the boxes as terms. The understandability is important here, not the completeness.

  • When a box links to a term, it means that it is clickable and it navigates directly to the definition of the term - this way the diagram serves as a navigation crossroads to related terms (add picture see an example of a term definition below).

  • Term clusters are a great help when we create our business dictionary: first we identify key entities and their relationships. Then we decide what entities / relationships deserve the status of a term in the business dictionary.



Clusters and conceptual/logical models

Conceptual models and their methodologies were our inspiration when we began working with term clusters. These models can be literally considered, on face value, as clusters of terms. Many vendors of BI and DWH platforms supply their solutions with conceptual / logical models of the customer's business domain. These same models viewed as term clusters can be used to complete the web of definitions used in the business dictionary. It's a win win situation; you create useful content for business users and it requires only a small  amount of effort.

However, there are a few drawbacks to conceptual / logical models:

  • When you have a logical model and want a physical one, the automation of the transition usually fails, because an expert needs to do several manual changes to optimise the result. Unfortunately, from this moment on, nobody wants to maintain the logical model any more...

  • A problem with conceptual / logical models is their need for completeness. They have to contain all the information necessary for the creation of the physical model. Which results in these models becoming quite laborious to make.

We, at Semanta have an alternative to workaround these problems:

  • sketch out your business concepts' network  (possibly in the conceptual / logical modelling style).

  • call the important concepts, "business terms", and define them in the dictionary - but don't bother about completeness.

  • invite data expert(s) to link the terms to the related data objects.

This way you have a natural and understandable map of your business concepts and their relationships. The map is clickable and links the user to an explanation in the dictionary where the user can learn how the business concept is related to the underlying data.


Term clusters and building a dictionary

How do you go about initiating such a system? It's quite straight forward. A few years ago we consulted on the creation of a business dictionary for our first client and we initially used hierarchies. The following problems occurred:

  • The dictionary's scope was unclear and it was difficult to decide what should be defined in it (sometimes terms were so general, it was like copying a wikipedia; other times they were so specific, they occurred too rarely to be useful).

  • It was difficult to identify how defined terms related to each other (what relationships were important enough to be mentioned in the definition of the term?).

The situation changed dramatically when we started to use term clusters. It was a great change: we simply organised a workshop with the relevant people. First we brainstormed what terms were related to the topic in question. We sketched out a cluster map of them on a flip-chart. Then we assigned tasks, saying who should define what. We asked data-experts to connect the business definitions to the data-world and a new well-defined part of the business dictionary came into existence.



Modelling techniques familiar to us from conceptual / logical models can be extremely useful when creating and organising a business dictionary. From our experience we've found that well-visualised networks of terms and their relationships are much more suitable for business dictionaries than hierarchies.