Is BPM a 4GL? It Boils Down to Your Perspective

  • October 30, 2011
  • Scott

Jacob Ukelson writes:

What I think surprised me most is how little BPM is used by most development and IT shops for their own use. Even when a truly structured IT process is being implemented (like deploying an application into production) – the tools are never based on BPM suites.

Interestingly, when I worked at a BPM vendor, we used BPM to run our builds, tests, and other automated processes (with, admittedly, some human-facing steps).  We also built our support site with our BPM suite.  Both decisions were fantastic decisions from the perspective of having everyone eat our own dog food, as well as making experts out of people who might otherwise not become experts.

Recently, I was talking with a startup that is into cloud infrastructure.  And they use a BPMS to make their deployments reproducible.

Two data points don’t make for a statistically significant sample.

A third anecdote sums up what I think Jacob is running into.  A few years ago I stopped by a friend’s startup in San Francisco.  He asked me what brought me to SF – long story short, I told him that my customer was using BPM to do some A/B testing around one of their core processes (a fulfillment process).  His response: “why do they need BPM for that?” and “why don’t they just write the code for that?”

Well, the first question – this is the question one always hears – not just with BPM, but with all kinds of new software or productivity tools.  As I like to say “why not just write everything in assembly right?”  After all – the question is are we using the right tool for the job, not whether other tools could theoretically do the job.

As to the second question – why don’t they just write code?  This is a pretty typical attitude for people who are really adept at writing code.  First, they don’t see a need to learn a new tool to get their job done – unless that tool is an API or a language. Second, they don’t see why anyone else should, either.  Third, they’re often suspicious of commercial software development tools vs. open source tools.  Fourth, they overestimate how many people of their skill level any given organization has at its disposal, and what else those same folks might be working on that is even more important.  What looks easy or obvious to them, isn’t obvious or easy to someone else.

The way I try to boil this down is that the more abstract ideas and organization you have to hold in your own mind, the harder it is to do something.  A BPMS gives you the ability to let go of some of those difficult abstractions (they become models) so that you can hold the same problem and solution in mind with less abstraction – by holding only higher level abstractions in mind.

Jacob worries that this might relegate BPM to a small niche, a la 4GL in the past.  It all depends on the definition of niche.  If a multi-billion dollar market is a niche, I won’t complain.  It was a niche when I started out in BPM.  It is a much bigger “niche” now.


Related Posts
  • August 27, 2019
  • Scott

Camunda continues to advance the state of the art for distributed workflow with the first production release o...

  • April 16, 2019
  • Lance

If you have been thinking about automation or performing small pilots, now is the time to get very serious abo...

  • April 6, 2019
  • Scott

Pre-amble.  A couple of weeks ago I attended the IBM Think conference in San Francisco. It was the first ti...