A number of people have asked me to explain the 'Spider Workflow' approach to workflow design, so I thought it would be best to blog about it. So here goes...
1. Introduction
There are a number of design cases in workflow solutions, where the 'order of steps' is now known or cannot be determined at design time. An example of this is where certain steps might occur more than once (eg: a specific manager needs to keep reviewing a document until conditions have been met), or where the user is involved in determining the next step of flow of events (eg: A user might wish to route a document directly to the regional manager (instead of the departmental manager).
Frequently during these types of solutions, the workflow designer attempts to solve this by linking each workflow step to each of the possible next steps in the process. This, however, can result in a very complex spaghetti workflow process with lines linking everywhere. There, in order to clean up this 'ad hoc' style workflow, one of the possible solutions is the 'Spider Workflow' approach.
2. Spider Workflow Approach
Spider Workflow is a workflow design approach in which the workflow gets handled by a central 'router' hub step, and a number of single 'spoke' steps. Using this approach, the workflow design is centered around an 'intelligent' central hub step, that determines which step (or steps) the workflow should route to next. (The spider workflow design could also (probably more accurately) be described as a 'hub-and-spoke' design). During the workflow runtime, the process will get routed from one spoke to another, until a specific condition (flag) is met such that the workflow is complete. In this manner, any spoke can follow a previous one (even the same spoke more than once if required).
3. How is it Built (Refer to the attached diagram below)
Referring to the diagram, the spider workflow is implementing using the Routing Step as the central hub. This is an activity that contains a single Server Event that evaluates data in order to set an 'Outcome' data field. Each line that emerges from the Routing Step contains a simple line rule that checks the value of 'Outcome' to establish whether it needs to be followed or not. (Example: the line that runs from Routing Step to Manager Approval could have a line rule that checks whether "Outcome==Manager Approval", and if yes, the Manager Approval would be the next step.
This can continue indefinitely until an 'exit condition' is met (depending on the solution). An example of this would be (referring to the diagram) the process might need to continue, once all of the 4 parties (Manager, Finance, Regional Manager and the CEO) have approved a specific doc. In this case the Routing Step would evaluate the Approval data fields, and if all 4 of them are set to 'Approved', then it would simply set the Outcome to 'Continue' (and potentially this would make the process continue to the Process Continues step)
4. Spider in Action (An Example)
Lets take a look at this in action. The originator might submit a new 'Policy Doc' and the process starts. By default the process has been built that if the user doesn't specify who this should be routed to next, it follows a default order (Manager -> Regional -> Finance -> CEO). Therefore, the doc gets routed to the 'Manager Approval' step.
The Manager takes a look but feels that the policy is too expensive, so he/she specify on their UI that the task must get routed to 'Finance Review' next. The Routing Step evaluates the data fields set by the Manager, and routes the task to the 'Finance Review' step.
The Finance team are happy with the doc, so they approve it, but do not specify a specific next step. The 'Routing Step' checks the default order, notices that the Manager has already approved, and the next default person is the Regional Manager, so then it gets routed to the Regional Manager.
The Regional Manager is happy with the doc, but he/she sees from the process history that the Manager routed it directly to Finance with some concerns. Therefore, the Regional Manager adds some additional comments, and routes it back to the Manager to review the doc.
The Manager gets the doc (for the 2nd time), sees the approval history and comments, and is now happy with the doc, and approves it again. The Routing Step now determines that the only person that has now seen the document is the CEO, so it gets routed to CEO Approval.
The CEO has a look, sees everyone else is happy with the doc, and approves it.
At this point, the process reaches a specific condition where the 'Routing Step' evaluates all the requirements and establishes that everyone that needs to approve the doc has already done so, so the workflow is routed to 'Process Continues' (where the doc might be uploaded to SharePoint, and the originator notified etc etc).
This is just a simple run-through of a single instance, however, it should be apparent that this process can be approved in any order, and number of times, all dependant on the conditions coded into the 'Routing Step' server event.
5. Extending the Design
This design can be taken a lot further than the simple scenario painted above.
5.1 Multiple Concurrent States
It is relatively easy to extend this solution to allow multiple concurrent steps in the workflow. There is no reason why this document cannot be reviewed by the Regional Manager and by Finance at the same time. One simple needs to add additional code/flags so that the Routing Step knows what to do in these circumstances. Fundamentally the process can get as complex as required, and the exit condition will always be 'if all confitions have been met, the process can continue'
5.2 IPC
Extending the design further, the spoke steps could be IPC (Inter Process Calls) to sub-processes. The only downside is access to the data, where the 'call-by-value' data passing to the child process means that child processes can only get/set their local copy of data fields that only get bubbled up to the parent upon completion of the child process. One can work around this problem by using SmartObjects that can be accessed from anywhere.
5.3 Mixed Model
The spider workflow is not an absolute workflow design. Any workflow process could at any stage include a 'spider-style' section, and it can therefore be used in a mixed model with classic (sequential) workflows, or even with other spider workflows (eg: where a spoke is effectively a hub for a sub-region). It all depends on the scenario.
6. Conclusion
To some degree, the 'Spider Workflow' approach has been over-hyped as the silver bullet for ad-hoc workflow. Basically this just a logical approach for flexible workflow design, that is very hard to report on (due to the vast number of activity (specifically routing step) instances) which makes it more difficult to measure the metrics of the solution.