Blog: The importance of images


Last autumn, I wrote an article on how the words we use play a significant role in defining IT systems. Ambiguous sentences, slang and abbreviations, excessive storytelling, and the language barrier often cause comprehension difficulties. Texts need to be revised and edited a lot to make them clear and understandable to different stakeholders.

All of this takes time and resources. However, there is an easy solution to this challenge, which we use far too infrequently. Why not draw an explanatory picture or diagram?

Images are universally comprehensible, so their message is more reliably conveyed even if the reader does not understand all the texts accurately. In particular, presenting the dependencies of things is often much easier with visual charts and tables than with plain text. Some of us have a good visual memory which makes it easier to remember graphically illustrated models.

What kind of chart would I make?

There are, of course, a wide variety of charts and models. In the field of IT systems, customers usually require a drawing or a picture of the operation (process) or the system (architecture). In this article, I will focus mainly on modelling processes, as they are most often encountered in the definition work. Good architects usually know how to visualise systems and like to do so.

Processes can be business processes that interest customers, or more technical ones describing how the system works. In any case, many of the same principles apply. Quite often the mindset is that drawing "boxes and arrows" is a good enough methodology. This is better than nothing, but potentially a big pitfall in even slightly challenging situations. Let's consider these questions:

  • What do the boxes represent: tasks, actors, or outputs?
  • Where does the process begin and where does it end?
  • Does it have different control flows if certain conditions are met?
  • Are there concurrent tasks, repetition, etc.?

My personal favourite in process modelling is BPMN - Business Process Model and Notation. It is intelligible enough to be understood by most professionals without major orientation. On the other hand, it has the potential to describe the process in more detail, if the need arises.

Different types of tools for generating BPMN diagrams are plentiful, and many are free. There are standalone tools, online tools, as well as plug-ins for wiki systems.

Below is a simple example of a review process in BPMN.

One great feature of BPMN models is that they can be explored or simulated by moving an imaginary game piece (or more) in the model. I think this is also a criterion from which to identify a good process model. In the example model, two pieces are needed because a parallel port (marked +) branches the process.


Why do we use diagrams or process modelling so rarely, even though there are clear benefits in many cases? Reasons can include:

  1. Lack of knowledge or skills. It is thought that modelling is somehow particularly difficult or laborious. New tools or models are not known well enough. 
  2. Prejudices. Modelling can have a bad reputation. It is true that in the early 2000s there was a great enthusiasm for modelling in the industry and it was done very meticulously in many organisations. Many exercises failed due to excessive expectations and promises and even good practices were rejected. It can also be argued that agile development would not require modelling. The optimum is, of course, somewhere between these extremes. 
  3. House habits. If the use of diagrams or models has not been part of the established way of working, the threshold for deployment can be high. 
  4. Hurry. Common thinking may be that drawing an image is too difficult and takes too much time. Instead, incomprehensible stories are written hastily. Soon we are really in a hurry when we have to explain and correct them. 

A step forward

I suggest you try it, it is not really difficult. Propose modelling to your coworker or supervisor. Well-founded suggestions are rarely not shot down, and then you can just test the matter in practice. You may be surprised at the positive feedback you receive when colleagues admire your work. Why wasn't this tried before!


Here are a few links to good tools and sites with additional information.