Workflow Doesn't work

According to a very learned and wise colleague of mine, while developers will always say that they are pro workflow, none of them really believe that it works. Personally, since being involved in a workflow project, I have always liked the idea. Its so neat and tidy, the yucky business rules that no developer really truly understands are zip-locked away in some XML document or modeling tool and we can just code neat little boxes that respond to requests from the workflow system. If the flippy types in the business change their mind about a process, you can just fiddle with the model. The code can stand stoicly firm, clean, pure and sexy in the twirly maelstrom of the business process.

I have to admit though, I have never seen workflow actually work. The workflow project I was on never got to technical implementation because they made a headcount save by rearranging the business units more efficiently after reviewing the business processes (the solution didn’t involve a .sln). Another colleague of mine says that ‘every insurance business in London runs on a workflow platform’ so I suppose the statement/heading at the top of this page is debatable.

I decided though to ask the question,

if workflow doesn’t work, what does?

This is very difficult, so I gave up on that question and decided to write down a few things about people and systems and work that I was pretty sure were true..Well it started off that way and went a bit pear shaped towards the end…Anyway, this is what I came up with.

Warning, Stream of consciousness follows

People at work have things to do

Systems at work have things to do

Things to do have only a few important attributes. What exactly to do, which people or systems can do them and when they need to be done by.

Sometimes people do the things to do, sometimes systems do them, it doesn’t really matter which. People are generally good at some things and systems are ,generally, good at other things. Some things to do can be done by either people or systems, the only difficulty with this is, often system friendly instructions and people friendly instructions look a bit different.

An object, for example, a data row or document is fixed in space, it doesn’t move (conceptually any way), it doesn’t flow, it is not in a pipeline, it is not transported, it is not itself a thing to do. A thing to do may contain references to objects. The format of these references is not really important, so long as a person or system can find the object or objects it needs to do the thing to do.

A lot of things to do are very similar each time we do them. It seems reasonable that things to do should be able to be copied from older things to do. Other things to do are completely new and novel, that’s ok to, as long as somebody or some system can do them.

Sometimes after doing a thing to do, it is appropriate to create another thing or things to do. For certain types of things to do, we may really know for sure what that next thing to do is eg. after receiving a fax instruction to move some cash into an account, the next thing to do should always be to call back the owner of the cash and verify the details…Often when this happens, some or all of the references to objects are passed along to the next thing. Sometimes there may be nothing to do next, sometimes you may not know what the next thing is until you have finished the first thing.

A thing to do is never done until you have created the next thing or things to do, or decided that there is nothing to do next.

People and systems need to know what things to do, they can do.

Systems like to have their things to do in a queue. Systems are good at processing queues.

People find queues depressing. When people look at the things to do that they can do, they may like to see these things floating, like little blobs of wax in a colorful lava lamp. When things to do are not very urgent, they might float low in the lamp where the colour is shady and blue. Inevitably, things to do become more urgent and may be seen to float upwards where the colour is brighter and more orangey. Things to do should never appear to flash, become underlined or jerk about wildly. A bit of bobbing on the surface may be ok though ;)

Author

Michael Dausmann

Full stack developer. Agile, Data science and Machine Learning. Love learning, speaking and dad jokes. Tweets are my own.