MidPoint 4.0, code-named Gutenberg will be major milestone in midPoint evolution. It is a major release, it is planned to be long-term support release and, of course, there is a bunch of new features. But one particular change is worth deeper explanation. I’m talking about policy-based approvals.
Similarly to almost any other IDM system, midPoint has started with integrated workflow engine. When midPoint was young this was quite an obvious thing to do. Something needs to drive the approval processes, right? And we want to make those customizable. And maybe, the workflow can be used to customize all the processes, eventually. And all the major competing products had workflow engine. Therefore, we haven’t really doubted whether workflow is needed or not. We just did it.
MidPoint has integrated fully-featured workflow engine for at least 6 years. But all that this engine was ever used for was to drive approval processes. There is actually no need for the workflow to do anything else. In fact, workflow engines in other IDM systems are often (ab)used to implement features that such IDM systems do not have. And this is often the only way how to implement something in closed-source systems. But midPoint is different. The midPoint way is to implement the feature in midPoint core – and then reuse it many times. We even have a special subscription model to support this approach from a business side. In addition to that midPoint already has plenty of better mechanisms for customization: mappings, expressions, hooks and so on. The result is, that no midPoint subscriber had no need to abuse the workflow engine.
Well, the workflow engine drives approvals. But in fact it does not do it incredibly well. Workflow engine is in fact just a simple automaton. It does not know who should approve the request. It does not know how to divide the request to atomic parts. It does not know how many levels (stages) and approval strategies are needed. In fact, it does not know anything about roles. It even does not know that the process is an approval process. All of that needs to be computed in midPoint. All that the workflow engine does is to interact with the user in a series of steps. And even that interaction is mediated by midPoint user interface. The value that a workflow engine adds to midPoint is very close to zero. But as workflow engines are quite a substantial pieces of software, the maintenance overhead related to keeping the workflow engine integrated is quite high.
However, there is one crucial reason why midPoint does not really need workflow engine. Many IDM systems are proud to claim that they are process-oriented. This makes perfect sense at a first sight. Business processes are inherently process-oriented, aren’t they? Therefore, it would be natural if IDM system also followed the process-oriented approach. But this thinking is misleading. There are many reasons for that and those may be a good material for one of my next blog posts. To keep long story short, let’s just say that it is much better to think about business rules. Not processes. Processes are often the same in their essence. There are just many process variations based on various circumstances. And those can be defined by the rules. MidPoint can use the rules to dynamically compute specific process for specific circumstances.
Let’s use approval process as an example. There are roles that do not need any approval. There are roles that has to be approved by managers. There are roles that need to approved by their owners. And sensitive roles may need even more approval levels. It is quite difficult to design an approval process that can handle all such situations and their combinations. User may request a set of roles that has few roles from each category. The process need to split that to subprocesses, otherwise the slowest path will slow down the fast paths. Each subprocess will need to analyze the roles, handle the stages, approval delegations, escalation and so on. And it needs to be done for each and every deployment. This is a nightmare. But it all gets much simpler when we think in rules instead of processes. Let’s just set up rules that specify which roles needs pass through which approval stages and who is supposed to be an approver for each stage. Then midPoint can compute the sequence of approval steps that need to be taken for each particular request. This algorithm needs to be implemented only once. And in fact, we have already implemented it and it is part of midPoint core. No need to reinvent the wheel for each deployment.
The bottom line is that midPoint does not really needs a workflow engine. The workflow engine does not add any significant value – and it has become a maintenance burden. Therefore, now it is the time to remove this relic early midPoint design. The workflow engine will be replaced with native midPoint functionality that was silently brewing inside midPoint for several years. This should simplify a lot of things. And almost all existing midPoint functionality will be kept as it is. In fact, MidPoint users and administrator should not even realize that an important midPoint component was changed.