Information modelling

The information model

What is an information model?

Contextual knowledge is imperative for understanding, so how can it be acquired and documented? Which documents and methods are suitable?

For the documentation part we draw on an established method that is familiar to many people as "conceptual data model" or "business object model". I call it quite simply information model.1 You have already seen an (incomplete) example in Figure 2 on page 11.

A typical data model produced by IT specialists looks like those in Figure 4 on the following page. Even if these models are correct and complete, they are utterly useless for communication between the business departments and IT2. The bones of contention:

 Overly technical presentation with too many types of symbol.

 Imprecise terminology.

 Too much information is missing, leaving an unacceptable leeway for interpretation.

Figure 4: Examples of data models.

It is hardly surprising that business departments feel unable or even unwilling to read, check, assess or accept these documents. Especially the latter aspect is often required in a hurry. They grudgingly do it in the hope that everything will be fine and because they would otherwise not receive their software. The presentation of these models is often accompanied by an Emperor's-New-Clothes effect: No one wants to be the first to admit that they have not understood the model. No one wants to express criticism or ask for clarification, as this would merely lead to yet another revision of the model, which could place an already tight schedule at risk. This takes us back to our initial proposal that misunderstandings lead to poor software (cf. page 8). Insufficiently understood models are implemented, producing software that mainly reflects what the IT specialists assumed it should be. The quality of communication between IT specialists and the customer determines the disconnection between IT's grasp of a subject and what the customer has understood and hence how well the software will be received.

The relational model - a well-known and an established method for database development (see [7]) - can be used to document the knowledge (context) of an environment. By adding the conditions listed below, it is turned into an information model and hence becomes what I believe is the best method for documenting and communicating informational aspects. An information model is a relational model, with the following added conditions:

 All entities and attributes express precisely what is meant. They can and must be taken literally at all times.

 For each term there is always precisely one qualifying definition (preferably based on a dictionary) or specification in the current area or project.

 All relationships between entities are described in both directions using an association (= a verb with a preposition as necessary).

 Everyone involved unconditionally understands and accepts the received nomenclature. It is expressed in a (natural) language in which all stakeholders are proficient.

 No information technology terms are used, such as index, key, mutation_user, field, view, int, column, 1:m, table, varchar, etc.

These rules appear self-evident and not particularly restrictive at first glance. But if you take a look at the words in italic type and attempt to adhere strictly to the constraints, you notice that it is not that simple after all. Actually you see that it is immensely difficult.

In my experience, the additions on the previous page make the biggest difference in facilitating comprehension and therefore produce better software. These constraints turn the data model into an information model.

Understanding this principle lends credence to the comment made earlier on that even the correct application of known methods can produce unacceptable results. Known methods are applied correctly, from a formal perspective at least, but they lack a semantic touch point with the real world, producing (technical) data models instead of (semantic) information models.

Some conditions like "all", "none" or "each" can easily be checked. But "exact", "unconditionally", "take literally" or "very good" are more difficult. They involve interpretation and a perception of meaning, and it is impossible to formalise meaning completely, which always depend on how the recipient of a message perceives its content. There are neither exact formulae nor verifiable rules that can guarantee correct or uniform understanding by everyone involved. And that is even before we consider whether the statements describe the original problem accurately and completely. This requires communication and discussion - one in which the points of view and perspectives are compared and in which a shared context is elucidated and defined. The main purpose of this discussion is to ensure that all the stakeholders are singing from the same hymn sheet, i.e. that they have a shared understanding of the statements.

It is only reasonable to assume with any degree of probability that the model possesses good quality once all potential misunderstandings have been dealt with. Achieving and verifying consensus is imperative and is the most difficult part of the modelling work. A tough job: Different viewpoints mus be harmonised - by conviction and not by decree; participants must negotiate individual words and their meaning; some interpretations must be scrutinised and revised. All stakeholders are personally invested, yet they might even have to rethink their own perceptions and interpretations. All too often, this personal concern and the frequently encountered reluctance to argue lead people to resort to platitudes. Statements like "We know what they mean", "I'm sure it's right, I don't need to understand it" or "Names are not so important" are merely the helpless attempt to avoid engaging with the key areas of the modelling process. There is only one thing to say about this kind of comment: If you don't say what you want, you get what you deserve.

Rules are needed in the modelling process to prevent people from evading things this way. Everyone on each level must be aware that their wholehearted agreement in regard to all details contained in the information model makes a crucial contribution to the quality of the future software system. Names and relationships do not become definitive until they have been found to be correct and accepted without any conditions whatsoever. And this only works if everyone has understood them.

The following example will help to illustrate what wholehearted agreement means.

Figure 5: A simple information model.

Take a look at the example in Figure 5. What does it mean? Strictly speaking, it only says that "book" has something to do with "branch" and "person". Whether someone takes it to mean that the person is reading, buying, borrowing, stealing or even wrote the book depends on the initial associations they have when looking at the diagram. These initial associations are determined by the personal context in which the person finds him- or herself. In other words, there is virtually no limit to the possible interpretations and hence almost infinite scope for misunderstandings that will likely remain undiscovered in this phase of the project development. Everyone is convinced that they have understood the model, but the only way to check whether everyone has indeed grasped it the same way is through discussion.

In the example, the associations between the entities are missing (refer to the third item in the list of conditions on page 17). An association linking two things is always expressed by a verb (possibly with a preposition as well), which states how the one entity interacts with the other/s, i.e. it describes the relationship between them. This is vital in order to ensure common understanding.

Figure 6: Seemingly clear information model.

The statements in Figure 6 are a little more exact. The diagram already contains many of the conditions that distinguish an information model from a data model: no technical jargon and wording that is understood by everyone. But the associations in the opposite direction are missing and unconditional acceptance of the literal terms and statements is probably missing as well. Take a moment to consider how you would understand the word "book" as it is presented in this diagram. Perhaps you are unable to tell by yourself which alternative avenues of interpretation are possible. Inevitably, however, you do decide on one understanding of the circumstances when reading the diagram. This then is your understanding. You may not notice that the diagram permits many different interpretations - and therefore numerous misunderstandings - until you discuss your perceptions with others. A strictly literal understanding of the statements by all stakeholders (managers, IT specialists, lending staff, readers, author, publisher's staff, sales staff, etc.) inevitably leads to questions such as:

Is the definition of the "book" that was delivered to a branch the same as the definition of the "book" that the author wrote? What do we understand the word "book" to mean? Is a person buying a book the same type of person writing a book? Merriam-Webster...