Orthogonal is one of my favorite words. From Merriam Webster:
1 a : intersecting or lying at right angles
b : having perpendicular slopes or tangents at the point of intersection
5 statistically independent
I don’t claim that I use it precisely correctly; I like to use orthogonal when I’m talking about something that intersects with the current topic or concept, but mentally feels like it cuts across the current concept.
Re-reading one of John Reynold’s post about task management and escalation, it reminded me of how I think of process, management processes, and process-definition processes… I think of them as being orthogonal in 3 dimensions. But let’s back up to John’s post on task management/escalation:
Basically he says you can either model these exception/escalations in your process, or implement as a service outside the process.
Digressing slightly – You should also think ahead in terms of how you’d support changing this policy at runtime. A centralized expression of the escalation policy is probably going to be easier to modify than distributed logic… and it’s probably a sure bet that the Business Folks are going to want to tweak these policies over time.
Bruce Silver, in the comments, postulates that you can still model this in BPMN as a subprocess with a non-interrupting timer start. While Bruce is right, there’s an implied overhead there if you have 10,000 of these processes – each with a dedicated “escalation” subprocess running to scan its items for escalation management. But there’s another way.
Consider the following diagram – a “single case process”, or as we normally say in BPM, a single process instance:
Basically, this is how most people thing of BPM and process: running an instance of the process, and how to make that more efficient.
But we should consider the “orthogonal” process that is the process of managing all of this process instance work. It would be responsible for monitoring the work, handling escalations or monitoring for when to produce escalations, and it would give a process manager tools for impacting work prioritization, etc.
This “case management process” that is orthogonal to the other process instances will enforce policies. And it can also be modeled or implemented in a modern BPMS. Think about it this way:
- the process to monitor the instances
- the process to escalate based on signals from monitoring
- the process to manage the process (related to escalation)
But that’s not all. We’re thinking in two dimensions now: Dimension Y is the process definition and our ability to run an instance of the process. Dimension Z is the management of a set of these process instances. There is a third dimension. Dimension X is the dimension of process improvement – future versions of the current process, optimized based on our learnings from running the processes and managing the processes. The process of improving the process:
Martyn A. Ould’s excellent book, Business Process Management – A Rigorous Approach, describes this perfectly. His terms are:
- A case process
- the case management process, and
- the case strategy process
So often BPM practitioners forget the second two types of processes. Or if remembered, they fail to apply BPM principles to these processes (you’ll hear some say that these processes are too creative for BPM, for example). But these are some of the most critical processes to design and maintain for the success of BPM initiatives… these are the processes that will likely help your organization extract the maximum benefit and value from your processes.
I have to give thanks were thanks is due – Derek Miers pointed me back to Martyn’s book and it was a good refresher read after years of consulting work between the first read and the second read- which allows for fresh insights.
(As I side note, I found it kind of interesting to see the mixture of case and process in his terminology, something the proponents of ACM have been frustrated with in current usage. The fact that this edition was published in 2005 tells you that it isn’t a new set of terminology).