The case for workflow modelling patterns

This article follows a series of workflow modelling patterns:

1. approval patterns
2. document patterns
3. collaboration patterns
4. email patterns.

A pattern language for architecture uses the idea that certain parts of buildings, or elements of urban planning, are recurring solutions to timeliness problems. These patterns create a language that architects can use to talk about their work at a higher level than at the (literal) building blocks of bricks and mortar. As process designers, we can do the same thing for process models.

In business process management we use different kinds of patterns to talk about process modelling. These pattern languages differ in their level of abstraction.

Low-level workflow patterns

Mentioning ‘workflow’ and ‘patterns’ in the same sentence makes some people immediately think of ‘Workflow Patterns’, with capital letters. Workflow Patterns is an academic initiative to describe the basic vocabulary of process languages and notations such as BPMN.

If you’re implementing a workflow engine, such as Signavio Workflow’s core engine, then Workflow Patterns gives you a useful language for the concepts that you implement on top of a programming language. If you’re a business user then you’d find these patterns too low level to be useful, which is partly why you’re using a tool like Signavio Workflow in the first place.

Complete business process models

As a business user, you’d probably rather have access to a repository of complete business process models that just happens to contain the exact model that you need, such as a recruitment process, an order to cash process, or something specific to your industry. Unfortunately, you probably won’t find a process repository like this, for various reasons.

• Companies rarely make details of their business processes public, because they perceive little or no benefit for doing so, because they want to protect their trade secrets, or even because they would be embarrassed if the world knew how they really work.
• Despite the success of the BPMN 2.0 standard, relatively few people can fluently read and write process models well enough that they would make sense to anyone else and be reusable in practice, even if companies did publish them.
• Other people’s models have limited usefulness, because it turns out that everyone does things slightly differently. You would probably spend longer understanding and modifying someone else’s model than you would modelling your own process from scratch.

Despite these issues, I do believe that the world does need a repository of open-source BPMN 2.0 process models that promotes discussion and variations on every model, but I’ll save that story for another day.

Reusable workflow fragments

If you find that low-level Workflow Patterns are too abstract, and that other people’s complete process models are too specific (or not available), then you might get more value from something in between. You won’t be able to use someone else’s Product Prototype process, but you can reuse the part that represents a document sign-off.

It turns out that complex business processes tend to include model fragments that commonly appear in a number of models. Examples include things like:

• Document Archive – saving a copy of a document’s final version
• Multiple Stakeholder Input – getting input on a proposal from multiple stakeholders
• Rejection Notification – sending a standard notification that an approval has been denied
• Request Form Approval – management approval for a request entered on a form
• Separate Complex Work – separating tasks that require specialist expertise.

Most business processes include one or more of these examples, which you’ll find in the articles linked below.

Workflow modelling patterns

To avoid confusion with Workflow Patterns (above), let’s call these reusable process model fragments ‘workflow modelling patterns’. In keeping with pattern language tradition, each one uses a standard template.

• Pattern name – a noun phrase that summarises the pattern’s purpose.
• Process goal – a verb phrase that summarises what the process fragment achieves.
• Examples – concrete examples of this pattern, as part of real-world processes.
• Context – when this pattern is useful and when not to use it.
• Structure – a process model diagram.
• Participants (a.k.a. collaboration) – how the elements in the diagram work together.
• Consequences – the trade offs between possible implementation choices.
• Related patterns – a list of other patterns that do something similar, or participate in a larger structure.

Earlier articles on this blog include the examples mentioned above, and a number of other modelling patterns:

• approval modelling patterns
• document modelling patterns
• collaboration modelling patterns
• email notification modelling patterns.

These are just the tip of the iceberg. Which process model fragments do you see again and again?

Photo: 準建築人手札網站 Forgemind ArchiMedia / CC BY 2.0