From IBM to PEGA: #1 The Process Definition

As an experienced IBM BPM (BAW) expert, I have recently decided to expand my knowledge with another BPM (Low Code) tool: Pega Platform. Starting with no experience on it, I have taken the studies for the Pega System Architect Certificate, provided by Pega Academy.

When transitioning from IBM to Pega it is inevitable to make comparisons between both tools. Every new aspect and functionality of Pega that comes under study has its counterpart in the IBM tool and that can result in similarities, slight differences or surprising new approaches, all of it with its consequences for the experience of the user and the potential of the tool.

I would like to go through some of them in a series of entries dedicated to this transition. And to begin with, probably the most significant thing to compare is the whole approach to the Process Definition, and most specifically the editor provided by the tools.

Process vs Case Type
The first thing that catches my attention is the fact that each platform gives a different name to their starring entity: Whereas IBM maintains the name as “Process”, Pega refers to it as “Case Type”. And this is something that becomes recurrent as one advances with the study of the Pega Platform. There is hardly a concept that has the same name in both tools. It seems like “this new tool wants to differentiate from IBM so badly that it has to change every single term”. Side note: this is probably material for a future blog entry. The result for me as Pega student is an enormous confusion with terms and concepts and much of a “what-a-mess” feeling.

At first sight one can see that these tools are using two completely different approaches: While IBM (on top) presents a definition based on a flow diagram with elements joined by arrows and distributed over user lanes, Pega uses a much more linear style, with lists of steps separated in consecutive stages.

Let us have a brief deeper explanation of each:

• IBM Processes are a series of tasks (squares in the image) that are executed in a certain order (determined by the arrows) by different actors (represented by the horizontal lanes). System tasks have their own lane. In addition, other components can be included in the diagram: conditional gates to implement decisions or split the execution, different starting and ending points, intermediate event handlers… Besides, the diagram can be divided vertically using milestones to represent stages in the process.
• Pega Case types define the Case Lifecycle like a series of stages (dark gray line in the image) that execute in a fixed order (left to right). Each stage is made of a list of steps (light gray blocks under the stages) that can be grouped in one or more processes (white container around steps). Processes within a stage can execute in parallel or sequentially. The role executing each step is configured in the step properties, not in the diagram. Conditions are implemented by one type of step. There is an underlying diagram representation for the processes, similar to IBM, to define more complicated behaviors.

Naturally, these differences have consequences in a lot of different aspects that we are going to analyze next.

Readability
The first aspect that comes to my mind is readability: Which approach is more adequate to define and describe a process? For me it is pretty clear, but maybe it is just what I am used to: A flow diagram is much more intuitive and understandable. We all know that a process is not linear, it may have loops, conditions and splits, and all these things are much better described in a flow diagram than in a plain list of items. Besides, the use of lanes in IBM for the different roles intervening in the process adds even more clarity to the diagram. Pega, on the other hand, does not reflect roles in a visual way: one has to access to the details of an item to look or define its routing.

This difference is important for a lot of reasons:

• Design: The process modeler can design more easily the process in a natural flow diagram style.
• Maintenance: Readability helps maintenance purposes. When someone different to the creator of the process needs to change, update or maintain it, a clean and straightforward definition saves a lot of trouble understanding the process.
• Communication: A more visual approach helps showing and explaining the process to technical and especially non-technical stakeholders.

Flexibility
Another implication of the different approaches is the flexibility that the developer gets from the tool. Such a structured solution as Pega provides limited possibilities to the developer. Meanwhile, an empty canvas that allows you to draw whichever combination of elements such as tasks, flows, conditions, starts, ends, events, etc enables the developer to model any kind of process variations. IBM just seems much more powerful and flexible.

However, it is true that as opposed to flexibility, usability can decrease as the complexity of the tool grows. Keeping it simple and more structured may provide more usability for simpler processes. Pega provides a number of predefined steps for the most common tasks in a process making it easy to add the underlying functionality. So when it comes to processes with quite standard functionality, Pega may be more suitable and easy to use.

Look & Feel
The UI of both tools also has some impact on the user. As silly as it may sound, the look & feel of the designer tool has a lot to say in this first impression from a platform. And my feeling with Pega is not as good as I expected. Having pictured a market-leading tool in my mind, the interface does not give me the impression of a super modern state-of-the-art technology. The buttons, context menus, forms and input fields have an old-fashioned look with a lot to improve. Compared to Pega, the IBM process designer looks like a much better finished tool.

Conclusions
After all these considerations, the process modeling approach by IBM seems to fit much better its purpose, in my humble opinion. Pega offers an apparently simpler tool, more structured, and therefore more limited, and it does not even compensate this deficit with a more attractive look & feel. On the contrary, it also loses in the comparison for this aspect.

But this is just one feature (an important one though). In following publications I will continue to compare some others that I find significant as well, and maybe Pega shows some upsides on those. Stay tuned!