Throughout the years I have created hundreds of K2 blackpearl processes and although the design of most of these were unique, there are two particular design patterns that stands out when creating new processes in K2 blackpearl.  These are waterfall or swimlane.

A waterfall tend to start  at the top of the design canvas and moves downwards flaring outwards like a waterfall.  A swimlane process starts from the left of the design canvas and stretch to the right and can continue on a new lane when desired.  Each new line represents a new lane.

The K2 designer has come a long ways since I started using the K2 product back in 2002 and probably all of the process I have seen back then used the waterfall approach.  Throughout the years the adoption of K2 by organizations increased tremendously and processes became more complex and a lot bigger in size as people discovered the true power of K2 blackpearl.  I soon realised that the waterfall design pattern is inadequate because it tends to cause K2 process lines to cross for complex, real world processes.  It tend not to take full advantage of the complete K2 blackpearl design canvas in that processes are designed from the top down leaving gaps in the left and right hand sides of the design.

Example of the use of waterfall design for a real world K2 blackpearl process

Although this does not sound like a big deal, there is an alternative better approach that brings order to the design and minimizes chaos that is generally associated with waterfall.  Enter swimlanes.

The ideas of a swimlane diagram is nothing new and I first encountered them back in the 90’s when I did my Computer Science Degree.  The basic idea is that you order your Workflow activities in swimlanes; each lane representing a role (i.e. User or Manager or System).  Lines then connect the Workflow activities and the overall result is a design that is ordered and easier to read and show to end users.

The notion of role/swimlane association in logical design is slightly different from that in a physical design in that the physical implementation’s roles are embedded within K2 blackpearl activities.  Thus, associating a swimlane with a particulat role does not really exists naturally.  Although this can still be achieved using the flexible K2 blackpearl designer, complex real world processes tend to get messy when using this approach because K2 process lines tend to start crossing the lanes when connecting K2 activities and this results in a messy design.

The basic methodology to implement swimlanes is surprisingly simple and keep a K2 blackpearl Workflow design very logical and neat even for very complex real world processes with lots of activities.  K2 IPC events should be used to split up complex processes but if it is absolutely required to keep K2 activities in a single process, swimlane will ensure a good design outcome.

Example of the use of swimlane design for a real world K2 blackpearl process

Start by aligning activities from the left hand side of the design canvas (top green arrow) to the right hand side and try and keep the number of activities that makes up the height of the swimlane to a minimum.  Although as many activities as you need can span the design canvas horizontally, it is good practice to create a new swimlane to minimize horizontal scrolling.  The idea is to equally fill the K2 blackpearl design canvas horizontally and vertically.  A new lane is created on the left hand side (bottom arrow).  Repeat this process until the complete process is defined.  Notice that re-work scenario’s lines neatly exit K2 activities from the top and enters earlier activities.

The power of neat and orderly design should never been underestimated.  Complex designs with multiple crossing K2 process lines are hard to read and is one of the reasons why the K2 blackpearl ViewFlow tool looses its usefulness when showing users K2 blackpearl process instances.  Swimlane design addresses this problem and gives you the best possible design layout.

Need further technical advice or support?