about processes and engines

“a brief explanation of workflow”

I write this in reply to that post from Al.

It’s a blog post, not an article. A better title for it could be “a brief explanation of the workflow context”.

Workflow systems are not new, they’ve been around since 30 years or so.

Workflows enacted by pieces of software are everywhere. But as soft as the ware might be, it may be really hard to modify it to adapt to changes in the real workflow it is meant to support.

Workflow management systems are yet another emanation of the will of software engineers to make their life easier by providing something that can adapt easily to change.

Everything changes, but there is granularity in change, class of things don’t change at the same speed. Workflow management systems identify two main class of things : workflows and organizational models (participants to workflows). I tend to include services (automatic participants) into the organizational model.

Workflows (aka business processes) may change without people/services being affected, and people/services may be replaces without affecting the processes.

Broadly speaking, a workflow engine takes then two inputs : a set of workflow definitions to enact and a set of participants to take part into those workflows.

What is susceptible to a higher frequency in change is exposed as a clearly delimited artefact : a workflow definition. Optimization and adaption drive the change frequency up.
The set of participants tend to change less (especially when it comes to people participant).

When talking of workflow system integration, there are two main approaches :

Either you embed the workflow system within an application, usually restricting the focus of the workflows to the scope of the ‘host’ application (for example when embedding a workflow system inside of a content management system).

Either the workflow system is shared by many applications and lies outside of them, ‘controlling’ the execution of business processes among applications/services and users (all participants).

There are more examples of the first approach in the software landscape than there are of the other. This first approach is easier to grasp by developers while the second appeals more to business users (but they need IT people to make this ideal real, and those same business users seem lured away by SOA these days).

Note on the terms chosen :

I prefer using the “process” term, but it could be confused for a process in the sense of an operating system process.

I like the term “business process execution engine”, but “workflow management system” is broader in scope and better known.

Written by John Mettraux

November 30, 2006 at 4:20 am

Posted in bpm, bpms, workflow

2 Responses

Subscribe to comments with RSS.

  1. I also took a swing at a history of workflow/BPM a few months back: This really covers a history of BPM products rather than workflow as a more generic concept, but may be of use in defining where we’re at now.

    Sandy Kemsley

    November 30, 2006 at 8:48 pm

  2. Hi Sandy,

    I follow your column, it contains lots of hints about what is going on in the proprietary bpm world. Thanks for adding the link here, it’s a nice ‘next step’ after this blog post.

    Best regards,


    John Mettraux

    November 30, 2006 at 10:53 pm

Comments are closed.

%d bloggers like this: