Models

An essential part of the analysis work is modeling certain parts of the business and IT in order to either understand it, document its as-is state, or outline the future state. The scope of things to model is quite broad, from organizational structure to database schema. Fortunately, analysts have a wide range of modeling techniques available and can select the best for each task. This is good news, but a hidden trap at the same time.

Since the number of techniques is big, an average analyst does not use all of them regularly, and hence cannot be expert at all of them. This is the cause of why so many analytical teams produce very pure models. Learning all models in depth takes a lot of time, which only a handful of analysts are willing to invest. For this reason, instead of trying to be another "UML/BPM/ERD/DFD..." reference, we will rather present what we consider the essential techniques, which, in our opinion, are beneficial no matter what project the analyst works on. Our goal is to describe only the basics without going into details that eventually only a few people understand. We would also like to go beyond the standard "modeling tutorials" and show how to apply the techniques in real life along with the dos and don'ts. The goal of this chapter is not just to teach drawing a diagram in a specific modeling notation but also to demonstrate how to use the specific diagram on a real project in a way that provides value. Difference between these two is similar to the difference between driving a car in a small village and driving a truck in downtown New York City.

Temporary Models Vs. Models to Keep

A model, like any other form of documentation, takes time to create and maintain, so the existence of every model must be justifiable. The first aspect to be considered before creating a model is whether the model should be created in the first place. Models must not be created just because some guidelines said so. There must always be a need for the model, and the model must provide some value.

If the author justified the creation of the model, the second aspect to consider is whether the model is valuable enough to be kept as a part of the documentation or whether it will be thrown away. This is a crucial decision that is going to influence how the model will look. If the purpose of the model is to explain a low-level system design to developers, it has a single purpose and will not be needed after the issue is clarified. In such cases, it does not make sense to create a perfect UML diagram in a supercool CASE tool when a quick whiteboard or pen-and-paper sketch would be enough.

On the contrary, if the model is a high-level overview, which is very likely to be used by dozens of people every time somebody would like to recall the topic, it would be worth considering creating a more formal model of higher quality.

Modeling Approaches

Depending on their purpose, models can have various forms and levels of formality.

Standard Notation or Free-Form Diagrams

A diagram notation means that the "boxes and lines", which the diagram consists of, have a semantics - it is agreed what each diagram element represents and what is its meaning. The good news is that analysts do not need to invent new notations themselves. Most aspects of business and IT could be modeled using already existing notations, be it UML for modeling systems, ERD for describing database entities, or BPMN for modeling processes. Using these standard notations has the benefit that regardless of the domain, organization, and project, the model is readable to everybody who knows the used notation. People will then be able to communicate using the common language, which makes the models shareable between teams and even between organizations. Nevertheless, it has also several disadvantages which may not be evident at first sight:

1. People have to learn the notation and the level of knowledge of the notation differs among teams
   • To embrace all modeling needs, the modeling standards became very complex. As a result, there are only a few people who know the whole UML from A to Z, for example, so most people use only a limited part of it anyway.
2. Business stakeholders may struggle to understand non-basic parts of the notation
   • We do not identify with the common belief that business stakeholders do not understand diagrams. The practice has shown, that if the notation is explained well, and only the basic elements are used, stakeholders pick it up very quickly. Nevertheless, more specific elements should be avoided.
3. Standardized diagrams do not cover all modeling needs
   • Modeling the standard aspects of business and IT such as processes or data can be easily done using existing unified notations such as UML or BPMN. But despite the complexity of these standards, they were not designed to model everything. In cases where the standard notations are not sufficient, a so-called free-form diagram can be used, which does not have any formal rules, so its modeling potential is virtually unlimited. On the other hand, it will not be readable without an explanation of the semantics.

Diagrams vs. Models

So far, we have been using the terms diagram and model interchangeably. We interpret the model as an abstraction of something - it is a simplified description that helps understand complex systems. As such, it has basically the same meaning as a diagram, which is a simple drawing that outlines the form or workings of something.

Even though we are going to continue using them as synonyms in most situations, we will also need to understand the other meaning. From the perspective of enterprise modeling, the model means more than just a drawing. Model is a data structure holding all information about various elements that form the enterprise and relationships between them. Having a model means having data about the elements, which can give answers to questions such as: "Who uses this service?" or "What are the attributes of this table?". The purpose of creating a model is not just to capture some information visually but also to continuously build up a database of objects, their attributes, and relationships between them. Having such a repository then allows us to quickly discover relationships between various aspects of the enterprise or to query the database to find out dependencies. Besides, the database is being built up automatically - drawing diagrams automatically creates the containing elements and relationships in the repository.

On the other hand, creating a diagram means just drawing a picture. Even though the semantics of the diagram elements is known, the result is just a group of shapes and lines. Since there is no underlying repository behind the shapes, it is not possible to work with the elements as if they were objects. A diagram is nothing more than just one of the possible graphical representations of the model.

So does it mean that diagrams should not be used? Definitely not. Drawing a quick sketch or a hand-drawn diagram is very easy and effective, so if the goal is just to communicate something visually and the output is not supposed to be kept, a simple diagram is a good choice. But there is no single criterion that would decide whether to create a simple diagram or whether to start building a robust model. As with most analysis approaches, it must be evaluated on a case by case to find out what will work in the given situation. You may work on a rigid waterfall project and be in need to quickly sketch a free-hand version of the to-be process just to show it to stakeholders to get their first opinion. On the other hand, you may be part of a rapid, agile environment, yet due to the project complexity, you will have to create a robust model to manage dependencies between systems, processes, people, etc.

When a diagram is usually sufficient

1. The purpose of the model is to clarify something rather than to document it
2. The modeled aspect is still changing a lot, and rework of the complex model would be expensive
3. The modeled aspect includes abstract elements which will never be part of the repository (see the example in the Free-Form Diagram section)

When to consider creating a model

1. The modeled aspects are stable and general enough, so they will not change often, and it will be beneficial to document them for future reference. The elements will be reused, and it may be needed to query them along with their relationships.
2. The team draw a lot of diagrams which all share the same elements which make them hard to maintain (renaming an element means changing dozens of diagrams)

Multiple Models

To understand a problem thoroughly, it is very often needed to look at it from different perspectives by creating multiple diagrams. This usually involves combining static and behavioral views. The static view describes the structure and relationships, whereas the behavioral view focuses on the functions and interactions. The static view represents the what, meaning the components, and how they are related to each other. But the core value lies in the behavior - how the components interact and behave.

The need to create various views on the same aspect is why the concept of storing elements in the repository and reusing them across multiple models was created. The individual views share the components, which saves time when creating the diagrams, and it also streamlines the maintenance as each change is immediately propagated to all diagrams.

Good Practices

1. Select Diagram Style

Each diagram could be drawn in a standardized notation with all elements perfectly aligned, but it could also be drawn as a group of ad-hoc boxes and lines captured on a paper tissue. There are situations when a formal diagram provides the biggest value, but very often, a simple whiteboard sketch will do the job with minimal effort. The author must always understand the purpose and the audience of the diagram and must evaluate the appropriate style accordingly.

Modelling standards are nice, but more important is to use notation that your audience actually understands.

— Scott W. Ambler

2. Do Not Tune Models to Perfection

All models are wrong but some are useful.

source: Wikipedia

The goal of modeling is to simplify reality, so models never include the whole picture of the modeled aspect. Do not try to model every detail of the problem, focus only on communicating the essential things. If the goal is to outline the core communication paths between systems, it does not matter that the model does not cover all interfaces. Sure, it does not reflect the full reality, but it was not even the purpose. The model must conform to its purpose, so just be sure that the audience understands it, so they do not take it as a comprehensive list of all interfaces.

3. Follow Modeling Conventions

The core skill in regards to modeling is doing the right model, meaning that the most appropriate diagram is used to clearly communicate the problem. Equally important skill is doing the model right, which means following the common modeling conventions. In an ideal world, the reader should not be able to tell if the models have been created by a single author or a team. This is obviously not realistic, yet all diagrams should at least look similar, drawn using the same modeling style. Additionally, the applied modeling rules and style could greatly influence the readability.

1. 7 +/- 2 Symbols
   • Complex diagrams are hard to read since the readability of the diagram rapidly decreases when the diagram constitutes of more than 9 elements. For this reason, the diagram should contain between 5 and 9 elements to be easy to understand while still providing value.
2. Break up Complex Diagrams
   • Complex diagrams which consist of more than 9 elements should be decomposed to multiple smaller diagrams
3. Diagram Layout
   • Minimize Crossing Lines - although it cannot be eliminated entirely, the fewer crossings are used, the better and cleaner the diagram looks
   • Orthogonality - diagrams look more clear and organized if the elements are placed evenly, and all lines are either horizontal or vertical. Bendings should have right angles.
4. One-Way Diagrams
   • Diagrams depicting a flow, such as activity diagrams, should be organized in a one-way fashion, meaning the flow starts on the left and goes to the right or from top to bottom. It should not jump from left to right and back.
5. Consistently Sized, Sensible Colors
   • All diagrams elements should be consistent in terms of size and colors. Of course, some key elements might be highlighted by making them bigger to show the importance, yet this should not be a common practice. The same applies to colors. Use them wisely and don't make the diagrams colored as the traffic lights.
6. Naming Conventions
   • Throughout Effective Analysis, we advise naming artifacts consistently. The same rule applies to diagram elements. Use cases, activities, or classes have their own naming rules, which must be respected in diagrams too.

And remember...

Model is like humor. When you have to explain it, it's bad.

(inspired by Cory House)