The Humble Work List
- June 13, 2018
- 0 Comments
Keith Swenson weighs in on “Worklist Performance Considerations“:
This is a technical deep dive into system design around providing a worklist to workers in a BPM system, and the technical tradeoffs you will encounter.
This is a topic near and dear to our hearts at BP3:
- We probably deploy more work list solutions to our clients than most teams our size
- We are typically deploying work lists against process engines as the core platform
- We have a great product offering to address work lists: Brazos Portal (which, to be fair, might more accurately be named Brazos Worklist).
Keith does a great job laying out the fundamental assumptions that make a work list different than just a to-do list:
- you have defined processes (likely in diagrams) that describe work
- this work is displayed to people in a list
- the individual person finds and selects work to do next from the work list
- these work items are assigned by some algorithm based on team, skill, or workload
Keith then explains all the technical performance issues for scaling such a system. Trust me when I say that a system that works fine for 10 users may not for 100, and a system that supports 10,000 or 1,000,000 users has a whole different set of design criteria. He gets into the intricacies of adding and removing users from groups, refreshing assignments as group membership changes or task status changes, etc. :
An alternative to group level work items, is an option to regenerate all the work items in the system. That is, walk through all the process instances that involve the group “Reviewers” and regenerate all the work item records. This will typically delete the existing work items, and then create 6 work items now that there are six people in the group.
This has the advantage that Frank can now just do a search for work items assigned to Frank and see all the reviewer tasks, but this is not instantaneous. The group is changed, and then the refresh operation is done, which might take a few minutes and might not be scheduled until later. Refreshing the work items on a large BPM installation can be a serious hit to the resources. If you have 1 million processes, this operation along might take the bulk of 20 minutes of server time, or at the very least put a serious load on it that effects everyone else. This is contrasted to the group level work item which produces absolutely no additional load when adding or removing people, but causes some additional complication by having to check multiple work lists.
It turns out that you can design systems that work well for very large organizations – that still scale down to small deployments. Brazos Portal is such a system. Keith gives great examples of the tradeoffs – query all the org structures as needed, or update all the assignments?
We could add additional considerations:
- should each person request their task list from the server, or should the server push new tasks to their browser (or app) as they become available? push vs. pull.
- how much information should travel over the wire?
- are we hiding personal health or financial information so that it doesn’t go over the wire inappropriately?
All of these items aren’t just functional considerations – they’re also performance considerations.
For this reason, BP3 has invested many hours of effort in building a robust Brazos Portal experience- one that federates work from multiple systems (even multiple diverse process systems) into one work list experience, even work from the cloud and from on-premise servers at the same time. We didn’t do it because it was easy – we did it because it is hard. Because individual clients and consultants should not be expected to engineer such solutions on their own.