• January 23, 2013
  • Scott

 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:

"Single Case Process"

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.

The Case Management Process

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:

The Case Strategy 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).


Related Posts
  • July 18, 2018
  • Ariana

We're pleased to announce all of the sponsors for Driven 2018. Automation Anywhere Camunda Bizagi ...

  • July 16, 2018
  • Ariana

Driven 2018 is coming up quick and we wanted to share some of our most anticipated sessions with you. You can ...

  • July 15, 2018
  • Scott

From nearly the first year I began writing this blog on behalf of BP3, pundits and commentators have predicted...

  • Supporting your comment that case/process terminology blending isn’t anything new – I was looking again at a Workflow Data Patterns paper from 2004 – http://www.workflowpatterns.com/patterns/data/ – and you’ll find Case, Workflow and Process terminology were used as needed… Ah, the good old days 😉

    • Right, the good ole days when no one was confused that case and process were of course going to be intermingled – after all, they both have to do with business process and management 😉

      • Comment from IDC:
        “The BPM market is evolving into something that more closely resembles application platforms. In this case, BPM — or case management — offerings are evolving into platforms used by enterprises to build and deploy custom business applications, and ISVs, as their next-generation packaged application or public or private SaaS offering.”

        • I agree that there is a fair amount of this “application platform” thing happening but the most troubled projects we see are the ones where they lost sight of process and are only focused on “application”…

          So there’s a bit of a paradox there. Not one I expect to see an answer to from IDC, but I think some of the software vendors are pretty sensitive to that issue (and certain consulting firms 😉

  • Had quite a few people ask me how I produced the drawings – I used Paper, an iPad app that I really like for capturing things that I would normally write on a whiteboard.