This article is here to compare three approaches to requirements analysis and business process modeling – Unified Modeling Language, Business Process Model and Notation, and Event Storming. The first two have an established position in the market and a certain degree of formality, while the third offers an entirely new way of describing businesses.
We will start this comparison from the most popular (and the oldest) one.
Unified Modeling Language
Overview
UML is a general-purpose, object-oriented modeling language. It was created in the mid-1990s as a first attempt to standardize the software modeling notation. It is a well-established solution widely used in many organizations. The organization maintaining it – Object Management Group – claims that it is used by over 70% of software development organizations worldwide.
Structure
UML has a lot to offer when it comes to describing systems. We have 14 different diagrams at our disposal. Using these diagrams, we can visualize the system in many different contexts and varying degrees of generalization. Diagrams are divided into two categories:
- Structure diagrams – focusing on the things present in the system. These diagrams are used to document the architecture of the system. For example, the objects diagram describes objects present in the system and the relations between them.
- Behavior diagrams – describing actions in the system. These diagrams are used to document the functionalities of the system. For example, the use case diagram illustrates the ways users interact with the system.
That’s a great tool, you might say. Why should I use something else?
Limitations
As we mentioned before, UML was created as a language. A pretty complex one – to tell the truth. Its specification consists of almost 800 pages. In order to use it correctly, you need to learn a lot. Every single detail is meaningful. Of course, you won’t be using all the diagrams all the time. Still, you have to know them all to pick the right one for the task.
You have to know the language to use it. UML notation’s complexity can limit the number of people involved in discussions only to those familiar with UML. This, in turn, may result in an incomplete picture of the business processes.
Business Process Model and Notation
Overview
BPMN is a graphical notation for business process modeling (as the name suggests). Just like the UML, it comes from the stable of Object Management Group (OMG). As you may assume, it’s not the only thing they have in common. Just like the UML, BPMN has a rigorous notation.
This is not the end of their similarities. You can use BPMN to illustrate the flow of the process – it’s very similar to Activity Diagrams known from UML. BPMN was created to allow business users and technical users to talk about the business process management. The concept of facilitating communication between technical and non-technical people was great. However, it finally resulted in a specification containing over 500 pages. Quite a lot to learn, you might say.
Structure
BPMN is a notation that provides many building blocks. This helps describe the modeled process logic in detail. Using this notation, we can illustrate the process in chronological order showing what actions need to be taken. We are provided with objects representing tasks, timers, rules, etc. We can illustrate decision paths in the process using a variety of logical gateways.
All the building blocks are closed in the contexts called “pools.” Each pool represents one business role and shows the flow of the process from that role’s perspective. Parts of the process may interfere between pools, showing how the users communicate with each other during the process.
Limitations
BPMN is giving us rich notation. That’s a plus. The market offers a variety of tools supporting it; another plus. So what seems to be the problem with it? It’s the same as with UML. It’s very complicated. Hence, there is a lot to learn before one can use it with ease. This may pose problems in discussing processes with people unfamiliar with BPMN notation. Additionally, the rich notation when modeling a complex process, can make the diagram unreadable in large scale. Partitioning the diagram into many smaller ones, on the other hand, can lead to difficulties in navigating between them, complicating the discussion way beyond what’s comfortable.
Event Storming
Overview
Compared to the approaches described above, event storming offers an entirely different experience. It is a workshop format for quickly modeling business processes and discovering the whole business’s big picture. It was first presented by Alberto Brandolini in 2013 as a blog post. Since then, it has evolved, and Alberto released an ebook about it.
Structure
(Almost) full notation is presented in the image above. I wrote almost because when describing the event storming notation Alberto Brandolini likes to refer to pizza. Every pizza has dough, cheese, and tomato sauce. The only differences between different kinds of pizzas are their toppings. And just like with the pizza toppings, everyone can extend the notation to their needs.
However, it’s not the notation that is most important during the workshop – its people participating in it.
After all, people involved in business processes are the ones that know those processes we try to capture best. The employees are the ones who follow those processes step by step every day. They are the domain experts of the business. Asking the right questions to the right people is the key to gaining in-depth knowledge of every step of the process. This is exactly what we need to fully understand the reasons behind particular business choices in a company.
During the workshops, participants use sticky notes as a method of communication. There are three levels of event storming workshops, and each level adds several new colors of sticky notes to the notation. Of course, the new color on the wall brings more details into the project view.
Big picture
The first level is a Big picture where we only use orange sticky notes representing events. During this workshop, we try to get an overview of the system. First, we “dump” to the wall all the events that come to our minds. We try to find the most important events for the system, and we arrange other events chronologically according to these “pivotal events.” As a result of the workshop, we should get an overview of events in the system. This level is the best to discover the full domain of the business.
This workshop format gives the most benefits compared to the effort involved. During the big picture, we ask a lot of questions about the business. We try to challenge the process we model to see if it can handle edge cases. Spotting a problem or an inaccuracy during the project’s analysis phase is the best that can happen. The earlier the problem is spotted, the easier (and cheaper) it is to fix it. To fix the problem in a big picture workshop, you have to change the place of a sticky note on the wall. To fix the problem in the production environment, you have to do a lot more.
Process level
Next comes a process level workshop. In that workshop, we focus on a single process, and we try to describe it in detail. As a starting point, we can take the result of a big picture workshop and add more information. We add information about data needed by users to decide what action they should do next. We also add policies controlling the flow of the process. At the end of the workshop, we are aware of all the decisions users can make and know based on what data they were taken.
Design level
What comes as the last one is the design level. This is the most technical level, and it is conducted mostly by developers involved in building the final solution. In the workshop, we try to find the so-called aggregates and business rules attached to them. As an outcome of the workshop, we get a full technical specification of a system where each type of sticky note can be translated into a specific building block in the system code.
Limitations
The workshop gives the best results when it is conducted in person. This means all the business experts need to gather in the same room at the same time. As we know, matching the calendars of many influential people in the company may be problematic. It may also be hard to convince the CEO of a big company to “play” with sticky notes.
Wrapping up
At first glance, it may look like we are comparing apples to oranges. On the one hand, we have serious tools with complex diagrams; on the other – the sticky notes. However, there are no problems in translating the outcome of a design level or a process level event storming workshop to a BPMN diagram. Methods described in the article are just different ways to achieve the same results – understanding the client’s business.
UML and BPMN are both well-established solutions. This is undeniably their great plus. However, it is also the primary source of their problems. You have to know them to make full use of them. Compared to them, Event Storming may look like a foolish game rather than a serious business tool. However, when you have a closer look, you can see that this is precisely the reason why it might be more useful. With both UML and BPMN, it’s the experts who talk. With Event Storming, everyone has the opportunity to speak.
