Ukelson: Is BPM the Next Studio for Software Development?

  • October 23, 2011
  • Scott

Jacob Ukelson has a fantastic critique of Agile Software – he lists the 4 pillars of Agile, but then points out:

These are all good, important points but they ignore the business perspective! […]

  • Business Value. Software must deliver business value, and that isn’t always completely aligned with user experience or any of the immersive points Mike lists. A application can have a great user experience but bring no value to the business, which means it will either be killed or die from lack of attention. In most cases business value needs to come first, and foremost.
  • Platform. Software (even what ends up as applications software) is either a platform itself, or built on (and used to enrich) a platform. This is both a business and technical decision, and can greatly affect the long term success of any software.

He has a point.  My interest isn’t so much in critiquing Agile Software methods – they’re pretty useful to BPM efforts, particularly if you keep the business value element in mind.

But the rest of the post makes a few interesting points, as he then turns the lens on BPM platforms to see how they stack up against both the 4 pillars of Agile, as well as the 2 additional “business” pillars:

  • Parallel – the modeling process is a bottleneck, but once completed things can be implemented in parallel

This is interesting.  I suppose in some BPMS environments, modeling itself is a single-threaded activity.  In IBM BPM and IBM BlueworksLive, modeling is a parallel activity.  In meetings reviewing BlueworksLive models you’ll often see multiple editors in action at once capturing feedback or updating the model in real-time.  In IBM BPM, the locking is at a very granular level, allowing for simultaneous editing. In earlier versions, the locking was more coarse-grained but still allowed for quite a bit of parallel modeling because subprocesses were not locked by editing other subprocesses or the parent process. On each of the rest of the points he makes, I agree with his assessment.

He sums up with:  “The problem is the distance between theory and practice. Most BPM suites try too hard to make themselves of value to the business side, and miss a lot of what is needed on the high-end development side.”  I don’t know if developers will ever lean toward using BPM suites independent of BPM efforts, but I do maintain hope that BPM suites will continue to add developer-friendly features as well as business-friendly features.  So far, I’m encouraged by the progress I see.



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...