Welcome!

Virtualization Authors: Carmen Gonzalez, Imran Akbar, Sharon Barkai, Elizabeth White, Liz McMillan

Blog Feed Post

Why Workflow and BPM Suck

The verities and the balderdash the impact of the cloud

I originally wrote this paper back in 2005 as a bit of a rant against the positioning of Workflow and BPM. I was reminded of it the other day and took another look only to discover that things still haven’t changed that much. So I’ve decided to revamp it a bit to encompass cloudy type things and what the impact of social media etc has had in the ensuing years. So for your amusement or edification here’s a revised version.

Many of us that were involved in the field of Workflow Automation and Business Process Management (BPM) a few years ago (and some still are I’m sure) argued long and hard about where the two technologies overlapped, where they were different, which mathematical models should be used, which standards were applicable to which part of the technology stack and all that associated puff.

Well these arguments and discussions are well and truly over more or less forgotten; the demarcation lines were well defined and drawn; the road ahead became clear.

The fact that Business Process Management has its roots in Workflow technology is well known – many of today’s leading products are, in fact, evolutions of the original forms processing packages. So there is no longer a need to debate, what is now, a moot point.

But what has happened is that BPM also changed. Rather than being an extension of workflow concepts BPM was seen as systems-to-systems technology exclusively used in the deployment of concepts such as SOA solutions. I’m over simplifying things I know, but it seemed as though BPM was destined to become an IT Technology solution as opposed to the business process solution it was meant to be. Somewhere along the way, one of the key elements in a business process – a person – dropped off the agenda. The fact that the majority of business processes (some 85% according to some very old Forrester research) involve carbon based resources was overlooked – think BPEL for a moment – doesn’t the attempt to develop that particular standard tell you something about the general direction of BPM? But be warned, even today, many vendors will tell you that their BPM products support Human interaction, but what they are talking about will be simple work item handling and form filling – this is a long way from the collaboration and interaction management we will talk about below.

The problem stems from the fact that most Workflow products were flawed and as a result, the problem in the gene pool rippled through to the evolved BPM species. So what was wrong with workflow? It’s quite simple when you think about it; most workflow products assumed that work moved from one resource to another. One user entered the loan details, another approved it. But business doesn’t work like that.

This flawed thinking is probably the main reason why workflow was never quite the success most pundits thought it would be; the solutions were just not flexible enough, since the majority of processes are unsuited to this way of working. Paradoxically, it is the exact reason why BPM is so suited to the world of SOA and systems to systems processes. A rigid approach to systems processes is essential, where people are concerned; the name of the game is flexibility.

Why do we need the flexibility?

Let’s take a simple analogy so that the concept is more easily understood.

Supposing you were playing golf; using the BPM approach would be like hitting a hole in one every time you tee off. Impressive – 18 shots, and a round finished in 25 minutes.

But as we all know, the reality is somewhat different (well my golf is different) – there’s a lot that happens between teeing off and finishing a hole. Ideally about four shots (think nodes in a process) – but you have to deal with the unexpected even though you know the unexpected is very likely; sand traps, water hazards, lost balls, free drops, collaboration with fellow players, unexpected consultation with the referee – and so it goes on. Then there are 17 more holes to do – the result is an intricate and complex process with 18 targets but about 72 operations.

As mentioned earlier, we have to deal with the unexpected. This is not just about using a set of tools to deal with every anticipated business outcome or rule; we are talking about the management of true interaction that takes place between individuals and groups which cannot be predicted or encapsulated beforehand. This is because Business Processes exist at 2 levels – the predictable (the systems) and the un-predictable (the people).

The predictable aspects of the process are easily and well catered for by BPMS solutions – which is why the term Business Process Management is a misnomer since the perceived technology only addresses the integration aspects – with the close coupling with SOA (SOA needs BPM, the converse is not true) there still iis an argument for renaming BPM to Services Process Management (SPM).

Proposals such as BPEL4People didn’t fix the problem either, all that managed to achieve is replicating the shortcomings of Workflow. Anyone who has tried to put together a business case for buying SOA/BPM will know the entire proposition will be a non-starter.

Understanding the business processes exist at 2 levels (the Silicon and the Carbon) takes us a long way towards understanding how we solve this problem. The key point is to recognize that the unpredictable actions of the carbon components are not ad-hoc processes, nor are they exception handling (ask anyone with a six sigma background about exceptions and you’ll understand very quickly what I mean). This is all about the unstructured interactions between people – in particular knowledge workers.  These unstructured and unpredictable interactions can, and do, take place all the time – and it’s only going to get worse! The advent of social networking, SaaS etc. etc.,  are already having, and will continue to have, a profound effect on the way we manage and do business.

Process based technology that understands the needs of people and supports the inherent “spontaneity” of the human mind is the next logical step, and we might be tempted to name this potential paradigm shift “A Business Operations Platform”. [1]

But what makes a BOP different from what’s gone before?

One of the key innovations (and there are many) is the collaborative nature of the platform. At last there is an environment that allows, encourages even, the business world and the technology world to align. Given that the business process is where these two worlds collide then the BOP becomes the place where the two worlds can achieve the most in terms of collaborative development and common understanding. Eliminating decades of misunderstanding. The Business Operations Platform does six main jobs.

It:

  1. Puts existing and new application software under the direct control of business managers.
  2. Facilitates communication between business and IT.
  3. Makes it easier for the business to improve existing processes and create new ones.
  4. Enables the automation of processes across the entire organization, and beyond it.
  5. Gives managers real-time information on the performance of processes.
  6. Allows organizations to take full advantage of new computing services.

Unlike early BPM offerings that were stitched together from fragments of technologies past, a BOP must be built on a standards-based and modern architecture.. With a service oriented architecture (SOA) and full BPM capabilities companies can create a complete business operations environment that can drive innovation, efficiency and agility for their enterprise. It must be Cloud enabled and capable of being deployed as BPMAAS as. It is the BOP that sets “enterprise cloud computing” apart from “consumer cloud Computing”

So why does workflow suck? It sucks because it made the fatal assumption that a business process was simply modelled as “a to b to c” – but business, as we all know, doesn’t quite work like that. BPM succeeds because of the heritage these products is in the workflow world – but BPM sucks as well because it ignores the requirement to include people.

Jon Pyke


[1] Since I wrote this paper Gartner coined the term “Intelligent BPM” but that begs the question as to what went before “Stupid BPM” ? So I’ll use BOP if that is OK with you the reader.

The post Why Workflow and BPM Suck appeared first on Cloud Computing Best Practices.

Read the original blog entry...

More Stories By Cloud Ventures

The Cloud Ventures Network is an expert community of leading Cloud pioneers. Follow our best practice blogs at http://CloudBestPractices.net