Ukelson: Is BPM the Next Studio for Software Development?

Scott Francis
Next Post
Previous Post
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.    

Tags: